Community
Participate
Working Groups
Hello, I am working on very big C++ project (~20k files). In this project there are many files with the same name but in different locations. These file relate to classes which have the same name but different namespaces. This is very common in this project. For example: Namespace1::Module - src/Namespace1/Module.++ Namespace2::Module - src/Namespace2/Module.++ When opening many files in editor their names are shown if ">>" button is pressed (please see attached screenshot). There is no way to differentiate between files which have the same name, without pressing (choosing) them. Possible solution, if file is focused by cursor its location will be shown as well. This is very important feature for all colleagues in this project. I don't think it is relevant only for C++ but for Java as well (classes with the same name but different packages). I opened it on C++ component but it is probably not correct component. Could you please dispatch it to correct component. Best regards, Yevgeny
Created attachment 125116 [details] problem screenshot
This is platform domain.
Not related to the fix, but possible workaround is to use another Eclipse UI presentation: http://andrei.gmxhome.de/skins/index.html This plugin allows you (beside other things): - show full path in the tooltip of the editor tab on mouse hover - show full tab of the editor in the editor list <ctrl+E> on mouse hover - always show full tab in the editor list <ctrl+E> by changing the editor list option
Hi Andrei, Thank you for your comment. I was not able to understand how to use the functionality you mentioned. > - show full path in the tooltip of the editor tab on mouse hover I believe this is ecplise basic functionality. On each opened editor tab on mouse hover full path is shown in tooltip. > - show full tab of the editor in the editor list <ctrl+E> on mouse hover > - always show full tab in the editor list <ctrl+E> by changing the editor What do you mean by showing "full tab" in the editor list? After installing this plug-in and opening editor list (<ctrl+E>), the behavior did not change (I am still not able to see full path of the files). Although "session" feature is cool :) Thanks, Yevgeny
Hi Yevgeny, you have to change the presentation: go to "Window->Preferences->General->Appearance" and change "Current presentation" to "Extended VS Presentation". After "OK" you will need to restart Eclipse once. Then you will see this picture: http://andrei.gmxhome.de/skins/full_tab_info.png (Taken from: http://andrei.gmxhome.de/skins/examples.html)
Yes a mechanism for plugins/editors to control the title text/icon of an editor tab would be fantastic. Of course a general platform approach may also work, but none has been forthcoming. From what I can see this and similar issues have been unanswered for years.
I am optimistic, hopefully this feature will handled soon by Eclipse guys. Regarding Andrei's solution, it does provide this functionality and more (although there were some problems - exceptions were thrown, ...). I would like to stay with classic eclipse appearance. I think this functionality will be usefull for many Eclipse users.
Created attachment 134175 [details] Show editor tooltip patch v1 This patch will show the editor's tooltip when the cursor is hovered over an entry. No images are rendered in the tooltip unlike the screenshot in comment 5 as it didn't seem that important to me (and would require make the patch more complicated than I would like it to be). The delay for displaying the tooltip is currently set at 200 milliseconds and the time the tooltip will stay up is "forever".
Created attachment 134271 [details] slightly simplified How about this one?
Comment on attachment 134175 [details] Show editor tooltip patch v1 (In reply to comment #9) > Created an attachment (id=134271) [details] > slightly simplified > > How about this one? Ooo, native tooltips, even better.
Paul, +1 for getting this polish item into RC1? It's a little late, but the issue comes up regularly on #eclipse (according to Remy).
*** Bug 242167 has been marked as a duplicate of this bug. ***
I think the patch is a good interim solution. It is not ideal as ideally you would only show the package and not the source folder (I assume that this is not a contraversial thing to say). There are many other things which might be nice, for example for the JDT different icons in the tabs for test classes... etc. Where this train of though leads to, and IMO the ultimate solution (which I would guess is not possible before 4.0), is that the platform needs to be made aware of source hierarchies and source folders, which means plugins would need to be able to register behaviours for source folders. So when the platform wants to find anything out about a file it first defers to the 'source container' (if applicable) and defaults to the current behaviour (basing everything on the extension). This could go much of the way towards unifying the navigator and the package explorer in the JDT(for example) and could make developing/maintaining eclipse based IDEs for other languages somewhat easier. Just my 2p
(In reply to comment #13) > I think the patch is a good interim solution. It is not ideal as ideally you > would only show the package and not the source folder (I assume that this is > not a contraversial thing to say). Hi, The idea of this enhancement was to be able to differenciate between files with the same name but in different location. Java files with with different packages is only 1 use case. There also C++ files with different namespaces (this use case is the most relevant for me ...), or any other files types. Is this fix relevant only for Java files or it will be applicable in general for files with the same name but in different location? BTW: when cursor is hovered over opened file (please refer to attachement screenshot2) it shows projectName/srcName/filepath/fileName. In my opinion the correct behavior is to show exactly the same information in our case. Thanks, Yevgeny
Created attachment 134366 [details] screenshot2
(In reply to comment #14) > BTW: when cursor is hovered over opened file (please refer to attachement > screenshot2) it shows projectName/srcName/filepath/fileName. In my opinion the > correct behavior is to show exactly the same information in our case. Yevgeny, this is what the patch does. I feel this is the least obtrusive solution and the most general (albeit not the greatest in UI or looks or whatever). I did not want to write a patch that would have extra bells and whistles which would effectively lower the possibility of it being accepted.
Created attachment 134413 [details] The dropdown CTRL+E with mangled names The dropdown names are mangled in Bidi (not part of this patch) but the tooltip paths that are shown by this patch are also mangled in BiDi. As an aside I noticed the name displayed in the java editor is also mangled. We should at least make sure the new code we are adding handles the BiDi paths correctly (and it wouldn't hurt to fix the dropdown). PW
(In reply to comment #17) > Created an attachment (id=134413) [details] > The dropdown CTRL+E with mangled names And because I wasn't clear, the mangled names are the 3rd and 5th entry in my picture (the last one is fine, my font just won't display it) PW
(In reply to comment #17) > We should at least make sure the new code we are adding handles the BiDi paths > correctly (and it wouldn't hurt to fix the dropdown). Since the list take its tooltip from the workbench part reference directly (via getTitleToolTip()), I suppose we will need to decide whether we want to perform processing internally in the platform (when part tooltip is set) or have it be up to the user.
(In reply to comment #19) > have it be up to the user. Of course, I mean, up to the people developing code on top of the Platform. See bug 274972.
(In reply to comment #20) > Of course, I mean, up to the people developing code on top of the Platform. It it probably up to us running the strings through TextProcessor, but I believe it is too late to do this for 3.5 now. Paul, do you agree?
(In reply to comment #21) > It it probably up to us running the strings through TextProcessor, but I > believe it is too late to do this for 3.5 now. Paul, do you agree? I agree that it's too late in 3.5 because we can't assume the nature of the tooltip passed to us (I did find out that TextProcessor won't change an already processed string). The original patch is fine, then. +1 PW
(In reply to comment #13) > I think the patch is a good interim solution. It is not ideal as ideally you > would only show the package and not the source folder (I assume that this is > not a contraversial thing to say). Of course it is, as Yevgeny's comment shows... Eclipse is used for more than just Java. Nevertheless, your comments are good, thanks for making them.
Hi, I think it is very important to give even intermediate solution for Eclipse 3.5, and for later release provide a better solution. In my opinion this feature is really needed as soon as possible. Best regards, Yevgeny
No worries, this will be in 3.5. Thanks for the voting from your co-workers! ;-) Patch ("slightly simplified") released to HEAD.
Verified in I20090507-2000.
Hi, I've tried eclipse 4 (Eclipse SDK Early Adopter Release, Build ID I20100727-1520). This feature is not working there. Thanks, Yevgeny
If you are finding bugs with Eclipse 4.0, please open them against Platform/E4 for now (3.x is a completely different code base). PW
(In reply to comment #28) > If you are finding bugs with Eclipse 4.0, please open them against Platform/E4 > for now (3.x is a completely different code base). > > PW I opened a new bug for e4: https://bugs.eclipse.org/bugs/show_bug.cgi?id=321294
Hi, I am working on: * Eclipse CDT Helios 32 bit. Eclipse IDE for C/C++ Developers Version: Helios Service Release 2 Build id: 20110218-0911 * Windows 7 64 bit * jdk 32 bit C:\Users\yevgenys>"c:\Program Files (x86)\Java\jdk1.6.0_31\bin\java n java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) We are using 32 bit Eclipse because of several "console view" issues that were observed. From time to time, tooltip on dropdown list (which was implemented in this ticket) do not work. At this time tootip on files that are not in dropdown list is ok. Restarting Eclipse did not solve this issue. After full Windows restart the issue was solved. Any ideas, what could cause this issue? Do you want me to open a new bug for it? Please let me know if you need any additional information. Thanks, Yevgeny
(In reply to comment #30) > Any ideas, what could cause this issue? Do you want me to open a new bug for > it? Please let me know if you need any additional information. > Please open a new bug. You'll have to determine if it works in Indigo (the current 3.8 is better). PW
