Community
Participate
Working Groups
Build Identifier: 20100917-0705 Steps to reproduce (CDT 7.0.1): 1. Define an include path as ${workspace_loc} in project settings 2. Observe that instead of pointing to workspace root, the Includes container in Project Explorer view shows the current project entry. The handling of workspace location as include path is missing in two places: 1.PathEntryTranslator.PathEntryComposer.valueToEntryPath() 2.CViewLabelProvider.getText() Question is how the workspace root should appear in the Includes container? Is there a common symbol (e.g. /) or should it be displayed as an absolute path? Reproducible: Always
Created attachment 183553 [details] Patch for the problem Updated the PathEntryTranslator to handle the workspace root path and CViewLabelProvider to display "R/" - toString() value of workspace root.
>Question is how the workspace root should appear in the Includes container? Is there a common symbol (e.g. /) or should it be displayed as an absolute path? In my vision it should be "Include folder in workspace" icon and "/" as a text. For folders in the project it should be "Include folder in project" icon and one of a) workspace path (including project name) or b) path rooted in the project. It should be consistent with presentation in "Paths and Symbols", bug 279502.
Created attachment 183648 [details] Modified to display "/" in Includes container The "/" text is reasonable, patch updated. Not sure how the "Include folder in workspace" icon looks like in HEAD. Currently, it has the same icon as "${workspace_loc:/OtherPrj/folder}" include path (blue in CDT 6.0, purple in CDT 7.0.1).
(In reply to comment #3) > Created an attachment (id=183648) > Modified to display "/" in Includes container Hmm, I do not observe "/" instead I observe absolute path of the workspace on the filesystem. Is that what is intended? > The "/" text is reasonable, patch updated. > Not sure how the "Include folder in workspace" icon looks like in HEAD. > Currently, it has the same icon as "${workspace_loc:/OtherPrj/folder}" include > path (blue in CDT 6.0, purple in CDT 7.0.1). Yeah, that's the one.
Oops, I wasn't checking the patch against HEAD. It appears that the logic of getting labels for Includes elements has changed since CDT 7.0.1. CNavigatorLabelProvider is now IStyledLabelProvider and therefore getStyledText() is called instead of getText(). Unfortunately, CViewLabelProvider wasn't adapted to implement getStyledText(). It has only getText(), which is no longer called and therefore all workspace includes are now displayed with full paths, not only the workspace root from my patch.
Created attachment 184263 [details] Updated patch for (HEAD) Added a trivial implementation of CViewLabelProvider.getStyledText() that reuses the existing getText(). Note that CViewLabelProvider.getText() was missing decorateText() calls which are used in super.getText() implementation (CUILabelProvider). If there are any text decorations, we should apply them to all objects, not some of them. Added the missing calls at return statements.
The root folder looks good but now presentation of other workspace folders is inconsistent since they do not have leading slash. Could you correct that as well?
Created attachment 184692 [details] Like in this screenshot?
Created attachment 184693 [details] Corresponding view of paths in project settings
Would it not be better to display this as an absolute path? Note that projects can live anywhere on the filesystem. So with this UI you're implying to the user: / /ProjA /ProjB/src that both ProjA and ProjB/src are realtive to '/'. In fact the project may live anywhere. The workspace root is useful when you're resolving workspace resources against it. However if you're using it as a file-system location in its own right, its location bears no relationship to the project locations.
And further note that while CVS & SVN may check-out projects directly under the workspace, ClearCase, Git, and plain-old filesystem import, likely have the projects nested elsewhere. Andrew: I thought you were keen on distinguishing IResource paths (resolved to locations at runtime) to hard-coded filesystem paths (different per user). The WR itself is one of the latter.
Created attachment 184697 [details] One more screenshot Here is another screenshot. It shows also the subfolders and the status bar. The status bar shows the full path, while Includes container shows the relative project structure of the workspace. Nothing changed here in the concept from previous implementation, showing the workspace relative path makes it clear that it is a project in the workspace, unlike any other path. The preceding slash doesn't make it more clear than before, but I don't have a strong opinion whether to have it or not.
Created attachment 184709 [details] Patch with the requested changes from Comment 7
(In reply to comment #10) > Would it not be better to display this as an absolute path? > Note that projects can live anywhere on the filesystem. So with this UI you're > implying to the user: > / > /ProjA > /ProjB/src > that both ProjA and ProjB/src are realtive to '/'. In fact the project may live > anywhere. > The workspace root is useful when you're resolving workspace resources against > it. However if you're using it as a file-system location in its own right, its > location bears no relationship to the project locations. I explained the rationale in comment#2. We are talking here about workspace resources represented as ${workspace_loc:/Project/path}. The presentation should be consistent with presentation in Paths&Symbols properties. If we let the user to enter workspace path in UI we should display it as workspace path the same way everywhere. This is not relative path to workspace location but workspace path as in IResource.getFullPath() and it is clearly marked as such by workspace icon IMO. Note that IResource.getFullPath() returns a path starting with "/". That does not imply that the path is relative to workspace location. (In reply to comment #11) > And further note that while CVS & SVN may check-out projects directly under the > workspace, ClearCase, Git, and plain-old filesystem import, likely have the > projects nested elsewhere. > Andrew: I thought you were keen on distinguishing IResource paths (resolved to > locations at runtime) to hard-coded filesystem paths (different per user). The > WR itself is one of the latter. What is your vision? Do you think we should always display filesystem path in PE? That path is very long line in many cases. I think that displaying workspace path is more succinct, expressive, and consistent and I like the last screenshot from Alex where the location on the filesystem is presented in status bar.
Perhaps my point wasn't celar. The issue is that in general the location corresponding to "workspace_loc" bears no resemblance to an arbitrary project.getLocation(). By displaying, in the UI, the variable "${workspace_loc}" as a 'workspace path' of '/' you're misleading the user. It implies that that '/ProjectA' is relative to the thing that looks like '/', which it isn't. I have no issue with projects, folders, etc starting with a leading '/', the only issue is with how you display the variable ${workspace_loc} itself.
(In reply to comment #15) > Perhaps my point wasn't celar. > The issue is that in general the location corresponding to "workspace_loc" bears > no resemblance to an arbitrary project.getLocation(). > By displaying, in the UI, the variable "${workspace_loc}" as a 'workspace path' > of '/' you're misleading the user. It implies that that '/ProjectA' is relative > to the thing that looks like '/', which it isn't. > I have no issue with projects, folders, etc starting with a leading '/', the > only issue is with how you display the variable ${workspace_loc} itself. IMO the distinct workspace icon itself denotes ${workspace_loc}, do you think it could be confusing? What if we display the path explicitly ${workspace_loc:/ProjectA/path}, would it do the trick? Although I like that slightly less as it more verbose.
(In reply to comment #16) > IMO the distinct workspace icon itself denotes ${workspace_loc}, do you think > it could be confusing? No, that's fine I think that's great. > What if we display the path explicitly > ${workspace_loc:/ProjectA/path}, would it do the trick? Although I like that > slightly less as it more verbose. No, no, it's fine to have: ${workspace_loc:/ProjectA/path} displayed prettily as <icon>/ProjectA/path. The problem is that ${workspace_loc} is resolved somewhere different. So include paths resolved relative to -I ${workspace_loc} are ${workspace_loc}/relative/path, not ${workspace_loc:/relative/path} I think that ${workspace_loc) itself should just be displayed as an external full location. It's the same difference as: ${workspace_loc)/ProjectA/path vs. ${workspace_loc:/ProjectA/path) The first is bad, the second is OK. Does that make sense?
Is the difference you see is that for the paths like ${workspace_loc:/ProjectA/path} dependent resources are managed as IResource, i.e. ${workspace_loc:/ProjectA/path/include_file.h}, and for workspace root they are not, i.e. ${workspace_loc:/}/include_file.h?
(In reply to comment #18) > Is the difference you see is that for the paths like > ${workspace_loc:/ProjectA/path} dependent resources are managed as IResource, > i.e. ${workspace_loc:/ProjectA/path/include_file.h}, and for workspace root > they are not, i.e. ${workspace_loc:/}/include_file.h? Not quite. The -I is a resolved to a real _directory_ location in the filesystem. The compiler resolves includes relative to this directory. The issue is that: ${workspace_loc:/ProjectA/path} != ${workspace_loc}/ProjectA/path The first is resolved using IResource API, the second is just string concatenation. Importantly ${workspace_loc:/ProjectA} may live anywhere (it may be ${workspace_loc}/ProjectA, it may not...). With linked resources ${workspace_loc:/ProjectA/path} may not live under ${workspace_loc:/ProjectA} * The only way to guarantee when two users check-out a project that the -Is work, is to ensure that ${workspace_loc:/ProjectA/path} is used consistently, not ${workspace_loc}/ProjectA/path So: ${workspace_loc:/ProjectA/path} should be displayed as: <ws-icon>/ProjectA/path Whereas: ${workspace_loc}/ProjectA/path should be displayed as: <absolute-icon>/path/to/workspace/ProjectA/path and: ${workspace_loc} should be displayed as: <absolute-icon>/path/to/workspace/ *http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-exttools.htm
> The issue is that: > ${workspace_loc:/ProjectA/path} != ${workspace_loc}/ProjectA/path I am not disputing this fact and totally in agreement with you on this one. I am trying to understand what is your logic regarding to workspace root. As far as root I am getting equation ${workspace_loc:/} == ${workspace_loc}. Do you argue that ${workspace_loc} is different than ${workspace_loc:/} and should be represented differently in UI? Isn't ${workspace_loc:/} correct to represent workspace root?
(In reply to comment #20) > I am getting equation ${workspace_loc:/} == ${workspace_loc}. Yes, true. > Do you > Isn't ${workspace_loc:/} correct to represent > workspace root? Well this is the crux of it. The "Workspace Root" is the root of workspace resources. ${workspace_loc:<ws_relative_path>} are relative to that workspace root. ${workspace_loc} when *resolved* to a location is no longer the workspace root. It's just a filesystem location. And workspace resources aren't relative to this location. As every user has a different resolved ${workspace_root}, as a base directory it should be shown as the absolute path, from which relative paths are computed, rather than '/'. '/' implies that other workspace resources are relative to it, which in this case they aren't.
Out of interest Alex, how are you using ${workspace_loc} as an include directory? Given you can't checkout resources directly under the workspace, presumably all your resources are project relative. Do you have #include "proj1/incs" in your source files or are you picking up headers not part of an eclipse project?
(In reply to comment #13) > Created an attachment (id=184709) > Patch with the requested changes from Comment 7 I looked at the code and it is very simple. I am happy with it. But there is one addition we discussed with James by chat... I'd like to learn about your setup first how you use -I${workspace_loc}. Can you satisfy our curiosity?
Andrew and I had a long discussion on this. From my POV the path ${workspace_loc} can't ever be used safely in a multi-user version controlled environment. This is because projects may live anywhere on disk (and users put them anywhere). So using the workspace location as the base for include lookup, for example, is a very bad idea. ${workspace_loc:/ProjName} is much better. Any path that works for one user is guaranteed to work for others as the project is the root of version control in eclipse. The Workspace Root shouldn't be treated as the same as other IResources as it isn't a general purpose IContainer. The root can only contain IProjects, it can't contain IFiles or IFolders. So ${workspace_loc} without any context resolves to a fs-location unrelated to the projects under the workspace. For these reasons, I think that paths like: ${workspace_loc} ${workspace_loc}/Proj should look different & need to be annotated in some way, so users are aware that such paths aren't safe for sharing. Either a warning annotation, or display them using the location rather than the full path.
This bug gets more attention than I expected. Bottom line, it seems reasonable to display the workspace root as full fs path for the reason that it might confuse users expecting /ProjectA and /ProjectB as if they were under the same fs parent folder. Also, when working in unix, it might be highly confusing having / and /Project/some/long/path that look similar to a real fs path. So, I'm in favor of not having leading slashes and to display workspace root as absolute path. To address your comments: (In reply to comment #23) > I'd like to learn about your setup first how you use -I${workspace_loc}. While working with CDT 6.0, I encountered a problem with handling of -I${workspace_loc}/Project/Path. This was fixed in bug 318738, but during testing of this fix with different include paths, I came across this problem. It is quite common though to have complex source trees in make based projects with some shared header files that reside one folder up to the source projects. E.g. /Top - root of all sources/headers /Top/Some/Path <- common headers are here /Top/Some/Path/Project1 /Top/Some/Path/Project2 /Top/Other/Path/Project3 With this source tree, the user can create a workspace in /Top/Some/Path without putting it under version control and define -I${workspace_loc} for Project3 as include path. This is not a common nor recommended case, but as of current state, the workspace include path is displayed completely wrong and we should fix it this way or another. (In reply to comment #24) > From my POV the path ${workspace_loc} can't ever be used safely in a multi-user > version controlled environment. This is because projects may live anywhere on > disk (and users put them anywhere). So using the workspace location as the base > for include lookup, for example, is a very bad idea. > ${workspace_loc:/ProjName} is much better. Any path that works for one user is > guaranteed to work for others as the project is the root of version control in > eclipse. In general case, it's a bad idea, in practice it works when the projects are agreed to be at certain location relative to each other, e.g. under same parent folder. The problem using ${workspace_loc:/ProjName} is that it doesn't work when the project is not imported inside the workspace, even if it is physically inside, the makefile is generated without -I switch, since it can't resolve the path. > The Workspace Root shouldn't be treated as the same as other IResources as it > isn't a general purpose IContainer. The root can only contain IProjects, it > can't contain IFiles or IFolders. So ${workspace_loc} without any context > resolves to a fs-location unrelated to the projects under the workspace. > > For these reasons, I think that paths like: ${workspace_loc} > ${workspace_loc}/Proj should look different & need to be annotated in some way, > so users are aware that such paths aren't safe for sharing. Either a warning > annotation, or display them using the location rather than the full path. As of the moment, include path is displayed relative to the workspace, not as it appears in the project properties. In other words, if an absolute path can be resolved to a workspace project path, then it is displayed as a workspace project path. The good thing about it is the succinct representation. When the referred project is removed from the workspace, the representation changes to absolute path. If the project is closed, but not removed, the icon changes to regular (yellow), but the path is still workspace-relative. This looks good to me, as Includes container is not intended to show how the path is defined in project properties, but to show to what resources it refers in the workspace. Regarding annotation, we should not add a warning annotation, these paths are valid and used in practice. Projects sometimes expected to reside at workspace folder, but not necessary be open in the workspace. The user always gets a path like ${workspace_loc:/ProjName} using the "Workspace" button. But if he manually types ${workspace_loc}/Proj, then he knows what he's doing. With the latest patch, I found that "${workspace_loc}/RefProj" is displayed without leading slash when the project is not in the workspace. If we still want the leading slash, I'll update the patch to take care of that, but imho the leading slash will be confusing in linux. Btw, without the patch, we have unrelated problem, the CViewLabelProvider.getText() is no longer called at all, it should be fixed in any case.
It's unclear when you say "full path" whether you mean workspace full path or fs location? Nonetheless, we're clearly talking about two different uses here: - Paths resolved in the workspace: ${workspace_loc:...} - Paths relative to the workspace location: ${workspace_loc}/... I agree that both of them are allowed and have their uses. However we shouldn't use the same icon for them in the PE display, as the former is resolved in eclipse with knowledge of project and link locations, whereas the latter is concatenated and assumes a fixed fs layout. So in fixing this, please don't make the two types look the same in the UI.
(In reply to comment #25) > So, > I'm in favor of not having leading slashes and to display workspace root as > absolute path. I agree, this would be clean.
(In reply to comment #26) > It's unclear when you say "full path" whether you mean workspace full path or > fs location? By full path, I mean file system absolute path. > Nonetheless, we're clearly talking about two different uses here: > - Paths resolved in the workspace: ${workspace_loc:...} > - Paths relative to the workspace location: ${workspace_loc}/... > > I agree that both of them are allowed and have their uses. However we > shouldn't use the same icon for them in the PE display, as the former is > resolved in eclipse with knowledge of project and link locations, whereas the > latter is concatenated and assumes a fixed fs layout. > > So in fixing this, please don't make the two types look the same in the UI. CDT 7.0.1 always tries to resolve the display of fs absolute paths and ${workspace_loc}/<path> to workspace project relative path and it succeeds when the project is in the workspace. When it doesn't succeed, then absolute fs path is displayed as is, but ${workspace_loc}/<...> display is a little different. Do you propose to completely change that and disable the resolving of these two paths to their workspace relative form and instead always display fs path?
(In reply to comment #27) > (In reply to comment #25) > > So, > > I'm in favor of not having leading slashes and to display workspace root as > > absolute path. > I agree, this would be clean. I don't agree. In Project Explorer, if you select a resource you see workspace path starting with slash in the status line and it does not cause confusion. Also, there is an option "Copy qualified name" in Package Explorer and that also gives you the path with leading slash. Finally, IResource.getFullPath() returns the path with leading slash as well. If you do not display leading slash in Includes node that suggests relative path which can be interpreted as relative to the project.
In all this discussion, please remember that it is very common that projects do *NOT* reside in the workspace in the file system. If you want to properly represent the location of a project, you need to use ${workspace_loc:/project}. Simply using ${workspace_loc} is actually meaningless and should be an error.
We are operating inside eclipse world and I think we should represent paths following rules of this world, i.e. workspace paths. Perhaps we should represent filesystem paths differently, i.e. with URI syntax?
(In reply to comment #30) > In all this discussion, please remember that it is very common that projects do > *NOT* reside in the workspace in the file system. If you want to properly > represent the location of a project, you need to use ${workspace_loc:/project}. > Simply using ${workspace_loc} is actually meaningless and should be an error. Agree with everything except the last sentence. Some users imply the location of a referred project under the workspace fs path, not necessary imported in the workspace, we should not take that option away from them if it is legal in Eclipse. Further on include path display: In CDT 7.0.1 path like ${workspace_loc}/Project is displayed as "Project" with purple icon if the project is in the workspace, if the project is closed or not in the workspace, then it appears as "Project" with yellow icon, not absolute path. How is it handled by other (not CDT) tools plug-ins?
For example, in Java, opening Plug-in Dependencies container, I don't see any leading slashes for referred projects in my workspace. So when a project is referred, no leading slash is used. I haven't seen any special symbol for workspace root in JDT plug-in.
(In reply to comment #32) > (In reply to comment #30) > > In all this discussion, please remember that it is very common that projects > do > > *NOT* reside in the workspace in the file system. If you want to properly > > represent the location of a project, you need to use > ${workspace_loc:/project}. > > Simply using ${workspace_loc} is actually meaningless and should be an error. > Agree with everything except the last sentence. Some users imply the location of > a referred project under the workspace fs path, not necessary imported in the > workspace, we should not take that option away from them if it is legal in > Eclipse. I do not think we should necessarily disallow that but we should discourage it. As we discussed with James, we need warning/error overlay on the icon (perhaps a stop sign overlay?) and a warning message in status line. Also, UI in Paths&Symbols and Settings should warn a user about such paths.
(In reply to comment #34) > As we discussed with James, we need warning/error overlay on the icon (perhaps > a stop sign overlay?) and a warning message in status line. Also, UI in > Paths&Symbols and Settings should warn a user about such paths. I've three arguments to leave it without decoration: 1) ${workspace_loc}/ macro should be considered the same as any other macro that gets resolved to a fs absolute path. That's how it is defined in Eclipse help and it is the same as ${PWD} for example. Using other macros is not safe in the same way. 2) Errors or warnings are not displayed on linked resources that were created using WORKSPACE_LOC macro. The argument that it is not safe applies exactly the same for this case, but it is expected that the user creates it for purpose. 3) Some projects have a strict constrain of zero errors and warnings. It's clear that as any other macro, this macro can find its uses and thus adding a warning in this case blocks a legitimate use of this feature. My proposal is to stick with (1), because that reflects Eclipse definition of this macro and it should be displayed that way in PE view. To avoid unintended mistakes, a warning message can appear in "Add directory path" dialog when adding a new include path with this syntax. (In reply to comment #29) > (In reply to comment #27) > > (In reply to comment #25) > > > So, > > > I'm in favor of not having leading slashes and to display workspace root as > > > absolute path. > > I agree, this would be clean. > I don't agree. In Project Explorer, if you select a resource you see workspace > path starting with slash in the status line and it does not cause confusion. Well, this is not so for Projects and this is not so any Java project or file displayed in Package Explorer. And this is not true for non source files in Project Explorer, e.g. makefiles. Only the source files are displayed with leading slash in Project Explorer. The current display in the status bar is completely inconsistent if we speak about it. After installing PHP, I can note that it's not true in PHP as well. We should align the status bar to Java/PHP display, since CDT doesn't live alone in this world. A workspace may have both C and Java. > Also, there is an option "Copy qualified name" in Package Explorer and that > also gives you the path with leading slash. Finally, IResource.getFullPath() > returns the path with leading slash as well. You're right, but this is different, the path is not displayed in UI that way, only copied to the buffer. I will post some screenshots from PHP/Java PE views. > If you do not display leading slash in Includes node that suggests relative > path which can be interpreted as relative to the project. Well, that's the current state and no one complained so far. I can't say for sure what's more confusing seeing it as now or seeing in Linux paths like /.../.../.../.../ with different icons, when one is fs absolute and another is workspace relative.
Created attachment 184855 [details] PHP Explorer No slashes and the icon in includes path is the same as for project. This makes it clear that it's a reference to a workspace project. Same was in CDT 6.0, now it has been changed.
Created attachment 184856 [details] Package Explorer in JDT No slashes, the folders in Plug-in Dependencies have the same icon as workspace projects except the "J". Pretty clear as well.
Created attachment 184857 [details] Status bar in Java/PHP Both look in sync.
Created attachment 184860 [details] CDT project resources in status bar Different resources are displayed differently in status bar. The project and makefile (not a source file) are in sync with Java/PHP screenshots above.
(In reply to comment #35) > (In reply to comment #34) > > As we discussed with James, we need warning/error overlay on the icon (perhaps > > a stop sign overlay?) and a warning message in status line. Also, UI in > > Paths&Symbols and Settings should warn a user about such paths. > > I've three arguments to leave it without decoration: > 1) ${workspace_loc}/ macro should be considered the same as any other macro that > gets resolved to a fs absolute path. That's how it is defined in Eclipse help > and it is the same as ${PWD} for example. Using other macros is not safe in the > same way. After sleeping on that I think I can buy that argument for plain ${workspace_loc}. In this case the path is the absolute filesystem path and the icon is also filesystem path. But with the stipulation that UI where the user enters it treats it as such as well and does not set the underlying ICSettingEntry with VALUE_WORKSPACE_PATH flag (which is outside the scope of this bug though). If the user intentionally enters ${workspace_loc:/} that will still formally imply workspace resource as well as any ${workspace_loc:/path} syntax - and presentation with workspace icon and workspace path. > > > > So, > > > > I'm in favor of not having leading slashes and to display workspace root > > > > as absolute path. > > > I agree, this would be clean. > > I don't agree. In Project Explorer, if you select a resource you see workspace > > path starting with slash in the status line and it does not cause confusion. > Well, this is not so for Projects and this is not so any Java project or file > displayed in Package Explorer. And this is not true for non source files in > Project Explorer, e.g. makefiles. Only the source files are displayed with > leading slash in Project Explorer. The current display in the status bar is > completely inconsistent if we speak about it. After installing PHP, I can note > that it's not true in PHP as well. > We should align the status bar to Java/PHP display, since CDT doesn't live alone > in this world. A workspace may have both C and Java. What I see in PE for Java for most resources is that resource name is shown in the tree (last segment of the path) and in status line it is as [name - path]. This way you would see for include path "/MinGW/include/c++/3.4.5/" something like [3.4.5] in the PE tree and [3.4.5 - MinGW/include/c++] in the status line. I don't think dismembering include path is the good way to display it in our case. The point of my example was that there are places in eclipse where workspace path is used with leading slash and it does not cause any confusion whatsoever. > > If you do not display leading slash in Includes node that suggests relative > > path which can be interpreted as relative to the project. > Well, that's the current state and no one complained so far. I can't say for > sure what's more confusing seeing it as now or seeing in Linux paths like > /.../.../.../.../ with different icons, when one is fs absolute and another is > workspace relative. I heard complains about it. I think the current state of representing "Includes" in PE totally sucks. There is no well defined logic behind it.
This definition is reasonable and matches James suggestion in comment #17: > ${workspace_loc:/ProjectA/path} displayed prettily as <icon>/ProjectA/path. > ${workspace_loc} itself should just be displayed as an external full location. With addition of comment #40: > If the user intentionally enters ${workspace_loc:/} that will still formally > imply workspace resource That is displayed as: <purple_icon>/ This implies comment #26: ${workspace_loc}/ProjectA/path is also displayed as an external full location. Same for includes defined as absolute fs path. In CDT 7.0.1, any include path location is resolved to workspace path if possible. That should be changed according to above. Is my understanding is correct?
(In reply to comment #41) > With addition of comment #40: > > If the user intentionally enters ${workspace_loc:/} that will still formally > > imply workspace resource > That is displayed as: <purple_icon>/ This is weird. ${workspace_loc:/} == ${workspace_loc} so it would be odd to display them differently. > This implies comment #26: ${workspace_loc}/ProjectA/path is also displayed as > an external full location. Same for includes defined as absolute fs path. That's one option. However it's a bit lossy as it would be ideal to display something to the user that implies: ProjectA/path relative to wherever the workspace is located. > In CDT 7.0.1, any include path location is resolved to workspace path if > possible. That should be changed according to above. > > Is my understanding is correct? Only paths like: ${workspace_loc:...} are workspace paths. Everything else is either: absolute (easy), or relative to some base (where the base may be resolved in the workspace, or may not be). We may not even know the base... At the moment we don't have a good way of distinguishing these. However we should at the very least support: - Paths resolved entirely in the workspace - Absolute paths - Relative paths (what do these mean?) There's a lot more discussion on this in bug 280677. It's not clear what the right answer is... My feeling is that tooling should contribute only workspace paths, or absolute paths to cdt.core, relative paths are problematic as they're relative to the directory in which the compiler was invoked which could be anywhere.
(In reply to comment #42) > This is weird. ${workspace_loc:/} == ${workspace_loc} so it would be odd to > display them differently. It's an attempt to divide between the two representations. The other way around is to always show it combined as "/ - <full fs path>".
I see a weird behavior in cdt_7_0 when {workspace_loc}/.metadata/.plugins/org.eclipse.core.resources/.projects/my_project is interpreted as a relative workspace path.
It does not appear we agree on representation of the paths in general as far as the icon or the label. This task is originally about ${workspace_loc} workspace root pointing to project location which is a clear bug. In this case I suggest to fix the text of broken label only i.e. display full filesystem path and open another bug to discuss representation of paths in PE. Would that be the least common denominator for this bug?
(In reply to comment #45) > i.e. display full filesystem path and open > another bug to discuss representation of paths in PE. Would that be the least > common denominator for this bug? I think that would be the best thing to do in this case.
+1 I'll update the patch.
Created attachment 187502 [details] Displays workspace root as absolute path This patch leaves the display of the includes as is, but fixes the display of include path defined as workspace root. The path is displayed as absolute path with a purple icon. Added missing getStyledText() as this is what is called in CDT 7. The super class is using the StyledCellLabelProvider.styleDecoratedString(), which I'm not familiar with, so just added Strings.markLTR() for BiDi support. Added decorateText() calls like in the getText() of the super class.
*** cdt cvs genie on behalf of agvozdev *** bug 330750: Include path defined as incorrectly displayed in Project Explorer view Patch from Alex Freidin [*] PathEntryTranslator.java 1.27 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/model/org/eclipse/cdt/core/settings/model/util/PathEntryTranslator.java?root=Tools_Project&r1=1.26&r2=1.27 [*] CViewLabelProvider.java 1.26 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/cview/CViewLabelProvider.java?root=Tools_Project&r1=1.25&r2=1.26
Applied on HEAD (8.0), thanks. Is the patch intended for 7.0.X? It does not apply cleanly there.
The patch is for HEAD. Thanks for applying.
The ${workspace_loc} is now displayed correctly. For the rest of this discussion, I opened bug 338543. Marking as Fixed.
