Community
Participate
Working Groups
There are a lot JDT markers in the Problems View where the context menu action "Go to Resource" is not available. (see screenshot) As far as i observed thats the case if and only if the "Path" field is empty (i.e. if the underlying resource has only 1 segment). Nevertheless there is a resource (the project) the action could jump to. Can someone please fix that. It is so annoying to search for the project manual.
Created attachment 286958 [details] Screenshot Problems View Context Menu.png
AFAIK PDE generates the warnings. It should be possible to link the warning to MANIFEST.MF.
(In reply to Andrey Loskutov from comment #2) > AFAIK PDE generates the warnings. It should be possible to link the warning > to MANIFEST.MF. there are also errors like "Project '...' is missing required Java project:" | Build path | Build Path Problem "The project cannot be built until build path errors are resolved" | Unknown | Java Problem which are from JDT (JavaBuilder.isWorthBuilding()) directly. They could link to the ".project" or ".classpath" file. However since those files are hidden by default i would prefer a jump to the Project in the Package Explorer if possible.
(In reply to Jörg Kubitz from comment #3) > (In reply to Andrey Loskutov from comment #2) > > AFAIK PDE generates the warnings. It should be possible to link the warning > > to MANIFEST.MF. > > there are also errors like > "Project '...' is missing required Java project:" | Build path | Build Path > Problem > "The project cannot be built until build path errors are resolved" | Unknown > | Java Problem > > which are from JDT (JavaBuilder.isWorthBuilding()) directly. > They could link to the ".project" or ".classpath" file. However since those > files are hidden by default i would prefer a jump to the Project in the > Package Explorer if possible. Hidden files can be opened, that's not a big deal. Jumping to Project is not possible. Please create new bug per problem type that has no resource, it must be done by the marker creator, not by Problems UI after that.
(In reply to Andrey Loskutov from comment #4) > Hidden files can be opened, that's not a big deal. yea, but then i would need a second step to "Show in"/"Project Explorer" or "Show in"/"Package Explorer" to be able to configure the project. But both Actions do not for with hidden files. > Jumping to Project is not possible. That's what i ask to change. > Please create new bug per problem type that has no resource, Ok, i will - but there is a resource: the project!
(In reply to Jörg Kubitz from comment #5) > (In reply to Andrey Loskutov from comment #4) > > Hidden files can be opened, that's not a big deal. > > yea, but then i would need a second step to "Show in"/"Project Explorer" or > "Show in"/"Package Explorer" to be able to configure the project. But both > Actions do not for with hidden files. > > > Jumping to Project is not possible. > > That's what i ask to change. > > > Please create new bug per problem type that has no resource, > > Ok, i will - but there is a resource: the project! You can't "open" a project to fix it, not in the sense of "open resource". Most issues you mention are pointing either to .manifest or .classpath files. If you wish to allow any arbitrary action be triggered via "Go to resource", you probably want to change the "Go to resource" to generic "Show me something where I can fix that" and redesign how Problems view works, so it can open preferences dialogs etc. Right now it requires a path to a *file*.
created Bug 575456 created Bug 575457 created Bug 575458
(In reply to Andrey Loskutov from comment #6) > You can't "open" a project to fix it, not in the sense of "open resource". > Most issues you mention are pointing either to .manifest or .classpath files. I'd like to point them to those file then. Just in case someone create a Marker on a non IFile resource (as is), i would like "Go to Resource" to behave like "Show In"/"Package Explorer" or "Show In"/"Project Explorer" (what ever which explorer is open). [added to org.eclipse.ui.internal.views.markers.ExtendedMarkersView.openMarkerInEditor(IMarker, IWorkbenchPage)] Otherwise i would like to deprecate Resource.createMarker() and suggest the subclassed IFile.createMarker(). Because the current implementation feels incomplete.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/184395
What about hiding "Go to resource" and instead putting the whole "Show In" menu in case of non-IFile?
(In reply to Mickael Istria from comment #10) > What about hiding "Go to resource" and instead putting the whole "Show In" > menu in case of non-IFile? There is a "Show In" menu. But as it requires to select a Handler it can not handle double click (which i typically use). I added the "show in" behaviour of the first handler to the double click. I do not seed a need to hide "Go to resource" (and i dont know how to).
(In reply to Jörg Kubitz from comment #11) > There is a "Show In" menu. But as it requires to select a Handler it can not > handle double click (which i typically use). > I added the "show in" behaviour of the first handler to the double click. > > I do not seed a need to hide "Go to resource" (and i dont know how to). OK thanks. In any case, the context-menu not really the topic of this bug, so let's not bother with it.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/185212 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4cc0af612e92e60bc0a62b03ff9025ab8a728d65
Created attachment 287132 [details] Initial state in pde perspective
Created attachment 287133 [details] After double-click
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/186289
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/184395 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3bdd5aa60d2a014d1840632763e5b14307e5a9d5
Merged patch resolves the issue for reported. Further issues should be tracked separately and new tickets be open for them in order to better identify best resolution for them.
(In reply to Mickael Istria from comment #18) > Merged patch resolves the issue for reported. > Further issues should be tracked separately and new tickets be open for them > in order to better identify best resolution for them. Could one provide a summary how exactly the system behavior is supposed to be now? I've followed discussion on gerrit but I still not sure what is merged without reading the code, which is not what I want to do now.
(In reply to Andrey Loskutov from comment #19) > Could one provide a summary how exactly the system behavior is supposed to > be now? I've followed discussion on gerrit but I still not sure what is > merged without reading the code, which is not what I want to do now. In the Java perspective, double-clicking on a marker which has no resource path will bring selection onto the project in the Project Explorer.
(In reply to Mickael Istria from comment #20) > In the Java perspective, double-clicking on a marker which has no resource > path will bring selection onto the project in the Project Explorer. Thanks. It is not a typo: *Project* explorer, not *Package* Explorer? So it will be opened if not there by default, or if it is not opened, nothing happens?
(In reply to Andrey Loskutov from comment #21) > Thanks. It is not a typo: *Project* explorer, not *Package* Explorer? It is a typo, sorry. It's the "Package Explorer" that's targeted here. > So it > will be opened if not there by default, or if it is not opened, nothing > happens? That's a good question and I'm not sure about the expectation in this case; but the current implementation seems to open the view if it's closed. This behavior seems good to me; but I don't have a strong opinion about it.
(In reply to Mickael Istria from comment #20) > (In reply to Andrey Loskutov from comment #19) > > Could one provide a summary how exactly the system behavior is supposed to > > be now? I've followed discussion on gerrit but I still not sure what is > > merged without reading the code, which is not what I want to do now. > > In the Java perspective, double-clicking on a marker which has no resource > path will bring selection onto the project in the Project Explorer. And in the pde perspective it still opens Git repository view, I assume.
(In reply to Lars Vogel from comment #23) > And in the pde perspective it still opens Git repository view, I assume. Yes, but the issue should probably be reported to PDE or EGit as the "Show In" menu shows a symptom of the same root issue.
I suggest to revert this current fix and go with the additional configuration Jörg suggested. I just tested this with a client who had Genuitec installed in one of his Eclipse. After downloading the latest SDK and double-clicking on a cycle error it tried to open the view from Genuitec even though it was not installed anymore. It gave an error "Could not initized view" or somethhing like that. Genuitec is just one example, of course. We also have this weird behavior in the PDE perspective and most likely in other perspectives. Better to introduce a new configuration option, rather than introduce unexplainable errors and behavior by re-using existing functionality. WDYT?
(In reply to Lars Vogel from comment #25) > I suggest to revert this current fix and go with the additional > configuration Jörg suggested. > > I just tested this with a client who had Genuitec installed in one of his > Eclipse. After downloading the latest SDK and double-clicking on a cycle > error it tried to open the view from Genuitec even though it was not > installed anymore. It gave an error "Could not initized view" or somethhing > like that. Did you report this issue to Genuitec or whatever else is responsible of showing this error (could be Platform) ? > Better to introduce a new configuration option, rather than introduce > unexplainable errors and behavior by re-using existing functionality. > WDYT? I strongly disagree. What you faced is a bug that is not related to this issue. Most probably, using right-click > Show In > Genuitec view (or whatever the view was) would have resulted in the same error, independently of this patch. We should fix bugs where they are instead of introducing public configuration APIs to workaround them.
(In reply to Mickael Istria from comment #26) > (In reply to Lars Vogel from comment #25) > > I suggest to revert this current fix and go with the additional > > configuration Jörg suggested. > I strongly disagree. What you faced is a bug that is not related to this > issue. Most probably, using right-click > Show In > Genuitec view (or > whatever the view was) would have resulted in the same error, independently > of this patch. No. The option to Open-with > Genuitec view was not available. The platform API did not show the view, as it was not installed. But the new functionality still did use it. So either the new functionality must also ignore that views are not installed anymore or be reverted.
(In reply to Lars Vogel from comment #27) > The > platform API did not show the view, as it was not installed. But the new > functionality still did use it. So either the new functionality must also > ignore that views are not installed anymore or be reverted. OK thanks. I think the current code is missing a guard to verify the referenced view is registered. @Jorg: can you please take care of this?
(In reply to Mickael Istria from comment #28) > @Jorg: can you please take care of this? It was good that you submitted my patch and Lars did try it in a real world usecase. We learned the hard way that the "take first" logic has dynamic behavior due to perspective contributors. That dynamic is not good. The double click action should always take me to the same fixed view per perspective. It needs to be configured per perspective. The only way is to extend the API for that. We should not make a default. Even though i am a frequent user of git perspective i do not know which view would best for the Git perspective. Selecting a resource in the git repository view did not help me in the past - the repository view feels like a dead end for solving problems associated with files/projects. From a user perspective: I am using eclipse for Java and Java only. My wish as a Java user is that any perspective would lead me to the package explorer. I wish the java ide would be shipped with java-centric views only, i.e. having a Java-Git perspective. Before starting on this bug i did not even know that perspectives have so much associated decisions. I always expected perspectives would only be a preconfigured set and layout of the available views. Now i learned they can totally change the available actions. I don't like that. However as long as that is the concept of perspectives the perspective owner should decide what a action is executed on a double-click - and not a perspective contributor as is.
@Lars: do you have details about how to reproduce the issue? It seems to me that WorkbenchPage.getShowInPartIds can return invalid ids; and the various consumers in ShowInMenu to verify the existence of a view description for this id before adding it to the menu. So the code here should do the same thing.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/186789
(In reply to Jörg Kubitz from comment #29) > (In reply to Mickael Istria from comment #28) > > @Jorg: can you please take care of this? > > It was good that you submitted my patch and Lars did try it in a real world > usecase. We learned the hard way that the "take first" logic has dynamic > behavior due to perspective contributors. That dynamic is not good. The > double click action should always take me to the same fixed view per > perspective. It needs to be configured per perspective. The only way is to > extend the API for that. We should not make a default. > > Even though i am a frequent user of git perspective i do not know which view > would best for the Git perspective. Selecting a resource in the git > repository view did not help me in the past - the repository view feels like > a dead end for solving problems associated with files/projects. > From a user perspective: I am using eclipse for Java and Java only. My wish > as a Java user is that any perspective would lead me to the package > explorer. I wish the java ide would be shipped with java-centric views only, > i.e. having a Java-Git perspective. > > Before starting on this bug i did not even know that perspectives have so > much associated decisions. I always expected perspectives would only be a > preconfigured set and layout of the available views. Now i learned they can > totally change the available actions. I don't like that. > However as long as that is the concept of perspectives the perspective owner > should decide what a action is executed on a double-click - and not a > perspective contributor as is. I agree. Can you please push a Gerrit which adds this additional configuruation? Having one additional configuration option is not as bad as doing strange things in some perspectives and depending on the installed plug-ins which we cannot control. As Eclipse is a extendable platform we cannot break existing functionality.
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/186813
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/186789 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=da9b5b8bf55aa5f34b11e30679d8beecad458192
The "showInId" is not a good enough name if it applies only to markers; it should be "showContainerMarkersIn" or similar which clarifies the goal. Or, if you want to keep this name, it should also applies to the "Show in" menu. Basically, this attribute should be used to prioritize one element over others in WorkbenchPage.getShowInPartIds so it's consistently used everywhere one would expect. The value of the new flag should be stored and accessible in IPerspectiveDescriptor API like anything else so it becomes safer and more consistent to use it. It seems to me that with the new patch, if some perspective doesn't define the "showInId", this feature will not work at all. So the benefit is lower for the wider world. If showInId is null, sticking to previous property of opening the first available view still makes sense; particularly for properties that do take care of sorting their extensions correctly.
(In reply to Mickael Istria from comment #35) > The "showInId" is not a good enough name if it applies only to markers; it Currently it is only used with markers. It does not prevent future uses in other usecases. > It seems to me that with the new patch, if some perspective doesn't define > the "showInId", this feature will not work at all. It just does not change anything. And that's good because we can not know if it makes sense in other perspectives: As far as i understand, the perspective owner has no influence how the perspective contributors change order of the showInId actions. Seems to be a pseudorandom order of contributors.
(In reply to Jörg Kubitz from comment #36) > (In reply to Mickael Istria from comment #35) > > The "showInId" is not a good enough name if it applies only to markers; it > > Currently it is only used with markers. It does not prevent future uses in > other usecases. Either we already use it for other existing use-cases (show in menu) now, or we define it to be only for markers. As it's an API, we cannot just leave things in between and expect consumers will feel comfortable with it. > It just does not change anything. And that's good because we can not know if > it makes sense in other perspectives OK > As far as i understand, the > perspective owner has no influence how the perspective contributors change > order of the showInId actions. Seems to be a pseudorandom order of > contributors. That's really the exact same issue as the order in the show in menu; so we should aim for a unified solution.
(In reply to Mickael Istria from comment #37) Other use-cases would be to use the automatic show-in action on other places that show references of one or more projects. But i don't know any view that annoyed me as much as the problems view. I don't even know any other list that lists projects. The other views that i use all have a tree where the doubleclick would expand the project node. I do not need the show-In Dialog to be sorted. But i am happy that i now do not need to open it anymore for problems.
Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/186813 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=0fc1ee5e973dab985cbfa47f6396848e36ace4ce
Thanks, Jörg. Please add to N&N.
As mentioned with more concrete details in other comments, the overall quality of the code and new API is not sufficient to consider it as resolved. I'll clean this up some time later.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/186894
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/186894 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=bfab362c5703231c6fd2677bef1128d7a1b9ed28
Jörg, can you update the PDE config for latest change?
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/186957
Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/186957 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=e161fd43a09f7a2c41e0fccc55607da661a0d14e
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/186289 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=28eedbd0dad560875e6274806a33ab3a7b563c50
(In reply to Lars Vogel from comment #40) > Thanks, Jörg. > > Please add to N&N. Jörg, please also create this entry in a way so that after developer knows how to update their perspective.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186960
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186960 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=5c10ac6eaf2d88b5e053a4879b3b21dd980866c0
Thanks Jorg!
The image in N&N is greater than 800px. As per instruction - "The image should be no more than 800 pixels wide" Can you upload an image which is less than/ equal to 800px wide?
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/187726
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/187726 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=18a6e63b7c6986f6274a3a441551cede5405d37d
(In reply to Vikas Chandra from comment #52) > The image in N&N is greater than 800px. Thanks for the hint. Done. What needs to happen that the webpage shows the updated version? https://www.eclipse.org/eclipse/news/4.22/platform.php
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/187784
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/187784 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=f3d90ac06df8046725f870cda38fea1d31949671
