Community
Participate
Working Groups
Created attachment 277252 [details] Screenshot of VScode If a new user to eclipse starts eclipse for the first time a very empty workbench is shown. The editor area is empty and the project explorer is also empty. Compare how VScode is doing this. They do two things: On the empty editor area they show some important shortcuts. In the "Explorer" view they show a text: "You have not yet opened a folder." Followed by a "Open Folder" button. Eclipse can improve in this area. Let's have a look at the project explorer: To tell the user what to do, the project explorer should present some explanatory text to the user telling him what to do.
Created attachment 277253 [details] Eclipse on empty workspace See how eclipse looks like on an empty workspace (in resource perspective)
New Gerrit change created: https://git.eclipse.org/r/135629
+1
Created attachment 277254 [details] Eclipse on empty workspace with my change This screenshot shows a first version for this. I opened the "Search" and the "Git Repositories" view for comparison because they both contain explanatory text. On the "Search" view I like the fact that it starts with the current state: "Now search results available." to then tell the user what he can do to see something in this view. I don't like that the text is in the top left corner. I find a centered text much better. On the "Git Repositories" view I like that multiple alternatives are given including some nice icons. I also like that it's centered. I think it also should start with the current state e.g.: "No Respositories available." and then continue with today's text. My change starts with a text inspired from the "Search" view and the layout inspired from the "Git Repositories" view. We could improve this in multiple ways: - A user may also start not by creating a new project but importing one. So we may also propose to start the import wizard. - We could provide multiple alternatives with nice icons like in the "Git Repositories" view. We could dynamically propose alternative based on the perspective just like the "File > New" main menu entry does. So on the Resource perspective we would get "Project..." - in the Java perspective we would get "Java project" and "Project..." - in the plugin development perspective we would get "Plugin Project" and "Feature Project" and "Project...". In addition to these we could always add the "Import" wizard as last step. Would is your opinion on this? In which direction should we go? Are there any early review comments on my patch?
(In reply to Matthias Becker from comment #4) > My change starts with a text inspired from the "Search" view and the layout > inspired from the "Git Repositories" view. OK > We could improve this in multiple ways: > - A user may also start not by creating a new project but importing one. So > we may also propose to start the import wizard. Yes > - We could provide multiple alternatives with nice icons like in the "Git > Repositories" view. Yes > We could dynamically propose alternative based on the perspective just like > the "File > New" main menu entry does. So on the Resource perspective we > would get "Project..." - in the Java perspective we would get "Java project" > and "Project..." - in the plugin development perspective we would get > "Plugin Project" and "Feature Project" and "Project...". In addition to > these we could always add the "Import" wizard as last step. Yes, sounds good. > Would is your opinion on this? In which direction should we go? Are there > any early review comments on my patch? I've already answered on the review. Would be nice to have this as reusable component for Packages Explorer, Navigator and Project Explorer.
(In reply to Andrey Loskutov from comment #5) > (In reply to Matthias Becker from comment #4) > > We could dynamically propose alternative based on the perspective just like > > the "File > New" main menu entry does. So on the Resource perspective we > > would get "Project..." - in the Java perspective we would get "Java project" > > and "Project..." - in the plugin development perspective we would get > > "Plugin Project" and "Feature Project" and "Project...". In addition to > > these we could always add the "Import" wizard as last step. > > Yes, sounds good. Do you know how the "File > New" submenu is populated based on the perspective and how we could do the same? Hopefully we can do this without adding addition dependencies to the org.eclipse.ui.navigator.resources plugin.
(In reply to Matthias Becker from comment #6) > Do you know how the "File > New" submenu is populated based on the > perspective and how we could do the same? See NewWizardDropDownAction and org.eclipse.ui.actions.ActionFactory.NEW
Good idea, but the Java perspective for instance doesn't even include the Project Explorer but comes up with the Package Explorer. An the modeling perspective of the Modeling EPP has a model explorer. The screenshots here show the Resource perspective. So have a consistently nice user experience across various Eclipses and perspectives, something like this would need to be done in several places.
(In reply to Thomas Wolf from comment #8) > Good idea, but the Java perspective for instance doesn't even include the > Project Explorer but comes up with the Package Explorer. > > An the modeling perspective of the Modeling EPP has a model explorer. > > The screenshots here show the Resource perspective. > > So have a consistently nice user experience across various Eclipses and > perspectives, something like this would need to be done in several places. Sure. I agree. But we can do it. Let's start with the project explorer, provide re-usable code and use that re-usable code on the other places as well.
I just uploaded a new patchset. In this I: - externalized the strings - changed the text to Dani's feedback - add dynamic list of actions a user can trigger to get some projects into the workspace. This list contains the perspective specific project wizards on top and is always followed by the "general project" wizard and the "import existing projects" wizard. - no longer put the text in the center of the view but on the top left corner (with some top and left padding) I will add screenshot how this looks in various perspectives. I still need to encapsulate this into a re-usable class so we can also use this in navigator and JDT's package explorer. Should I put this re-usable in to the org.eclipse.ui.navigator plug-in (the plugin where also the CommonViewer class is located)? Are the new x-friends declaration okay?
Created attachment 277287 [details] In PDE perspective
Created attachment 277288 [details] In resource perspective
Created attachment 277289 [details] In JAVA perspective (with project explorer)
A great idea Matthias. A very nice addition. Thank you. Why did you drop the "new wizard.." as proposed in your initial attachment 277254 [details]? I think it would be nice to also have that, maybe even replacing "general project" since that has no real value (arguably).
(In reply to Wim Jongman from comment #14) > A great idea Matthias. A very nice addition. Thank you. > > Why did you drop the "new wizard.." as proposed in your initial attachment > 277254 [details]? I think it would be nice to also have that, maybe even > replacing "general project" since that has no real value (arguably). I did not drop this. Only the text changed. Now as you write it a realize that my text is wrong. I will fix this in the next patchset.
Created attachment 277291 [details] With fixed text for the new project wizard (In reply to Wim Jongman from comment #14) > A great idea Matthias. A very nice addition. Thank you. > > Why did you drop the "new wizard.." as proposed in your initial attachment > 277254 [details]? I think it would be nice to also have that, maybe even > replacing "general project" since that has no real value (arguably). Fixed with this change. What do you think about the text?
(In reply to Matthias Becker from comment #16) > > Fixed with this change. What do you think about the text? It's fine but I wonder if it will clip on smaller displays. I fetched your patch but I cannot get it working. Alternatives: "Choose project type to create.." or "Choose project type.."
I wonder if this could become API on Viewer. Viewer.setEmptyViewerContents(Composite viewerParent)
(In reply to Andrey Loskutov from comment #5) > I've already answered on the review. Would be nice to have this as reusable > component for Packages Explorer, Navigator and Project Explorer. I did start on that in patchset 5 of my change. There I extracted the common code and re-used it for the "Navigator" view.
(In reply to Thomas Wolf from comment #8) > Good idea, but the Java perspective for instance doesn't even include the > Project Explorer but comes up with the Package Explorer. > > An the modeling perspective of the Modeling EPP has a model explorer. > > The screenshots here show the Resource perspective. > > So have a consistently nice user experience across various Eclipses and > perspectives, something like this would need to be done in several places. See patchset 5 of my change.
I just pushed https://git.eclipse.org/r/#/c/136279/ that also enables this in JDT's Package Explorer.
I did some usability tests with real users and adapted my implementation to their feedback. I just pushes these changes. I removed the "import project" option from the list of available options. The purpose of this text is to on-board new / occasional users. These user typically won't import projects from git / from a zip / from the hard disk. I re-worked the text of the option that starts the "New Project Wizard" to "Create others...". Usability tests with real users showed that the previous text was too wordy and therefor was hard to understand. "Create others..." only makes sense when you have multiple options. In cases where you don't have perspective specific project creation wizards (e.g. in the Resource Perspective) a simple text containing a single link is displayed. I also did an analysis for memory leaks (see the listeners) with Eclipse Memory Analyser. All listeners are removed correctly / all controls are disposed correctly. It would be great if we can merge this for M3. As I will be on vacation next week it would be great to merge this in the course of this week. Can somebody pls. review the changes?
Created attachment 277444 [details] No text when filters active This is what I see when there are filtered out projects.
(In reply to Wim Jongman from comment #23) > Created attachment 277444 [details] > No text when filters active > > This is what I see when there are filtered out projects. Works as designed. The explanatory text only appears when the workspace is empty. An empty project explorer because the user has filtered out all projects is another use-case. Here the user proactively did something (configured a filter). We should not mix the two. If we want to improve the UI also in these cases we should address this in a separate bugzilla.
(In reply to Matthias Becker from comment #24) > Here the user proactively did something The user did nothing in this case. Plugins may automatically create work projects and install filters to hide them like was done here.
(In reply to Wim Jongman from comment #25) > (In reply to Matthias Becker from comment #24) > > > Here the user proactively did something > > The user did nothing in this case. Plugins may automatically create work > projects and install filters to hide them like was done here. Yes ok. Understood. But again I would say this is a separate use-case. Do you agree?
Another question regarding my change: Is the location of the re-usable class EmptyWorkspaceHelper ok? Is it correct to put it into org.eclipse.ui.ide? I have put it into the org.eclipse.ui.views.navigator package which is API. Is this correct? Or is there a way where we can first provide it with "x-friends" to other eclipse plugins and later on (if needed) make "real" API?
(In reply to Wim Jongman from comment #25) > The user did nothing in this case. Plugins may automatically create work > projects and install filters to hide them like was done here. I am not familiar with RSE. I just read a little bit about it. Is the "Project Explorer" heavily used in RSE?
(In reply to Matthias Becker from comment #27) > Another question regarding my change: > Is the location of the re-usable class EmptyWorkspaceHelper ok? > Is it correct to put it into org.eclipse.ui.ide? > I have put it into the org.eclipse.ui.views.navigator package which is API. > Is this correct? Or is there a way where we can first provide it with > "x-friends" to other eclipse plugins and later on (if needed) make "real" > API? Ah, I did not catch that. I definitely should _not_ be API. I like the way you have set it up but the class is not ready as API. IMHO to become API: * It should not be final * It should not implement all those listeners but use composition instead, or even better, split it into two classes. One for the IDE with all the listeners and one for the control/layout handling. * Users should be able to provide their own empty control or override the empty control creation. * The automatic project creation empty page is specialized and should be a subclass of the more abstract class. * The empty part helper should move to JFace. Don't bother with x-friends unless that is required, which I don't hope. This stuff is notorious for not being cleaned up.
(In reply to Matthias Becker from comment #28) > > I am not familiar with RSE. I just read a little bit about it. Is the > "Project Explorer" heavily used in RSE? The RSE is just an example of a plug-in that hides a work-project with filters. The RSE is included in the JEE eclipse package, which is the most popular download. I quickly tested that package and out of the box, there is no work project created so your feature should work there.
(In reply to Wim Jongman from comment #30) > (In reply to Matthias Becker from comment #28) > > > > I am not familiar with RSE. I just read a little bit about it. Is the > > "Project Explorer" heavily used in RSE? > > The RSE is just an example of a plug-in that hides a work-project with > filters. The RSE is included in the JEE eclipse package, which is the most > popular download. > > I quickly tested that package and out of the box, there is no work project > created so your feature should work there. I want to test this myself. Can you pls. explain what exactly I have to do?
(In reply to Matthias Becker from comment #26) > > Yes ok. Understood. But again I would say this is a separate use-case. Do > you agree? I'm afraid i do not ;) I think the trigger should not be how many projects there are in the workspace but what the view is actually showing. If it is empty it is empty and then the Empty...Helper ;) should kick in. Don't get me wrong. I love the concept you are bringing to Eclipse and I think it should become part of the JFace Viewer framework: TreeViewer viewer = new TreeViewer(parent, SWT.NONE); viewer.setContentProvider(ArrayContentProvider.instance); viewer.setLabelProvider(MyLabelProvider.instance); viewer.setEmptyHelper(new EmptyWorkspaceHelper()); EmptyWorkSpaceHelper extends EmptyViewHelper implements IPerspectiveListener Having said all this. I am +1 if you want to push this now for M3 as an incubation trial.
(In reply to Matthias Becker from comment #31) > > I want to test this myself. Can you pls. explain what exactly I have to do? Sure. 1. Download the jee package 2. Open the remote system explorer perspective 3. Create a remote system 4. Switch back to the resource perspective 5. If your patch is included, close and open the project explorer 6. See the PE filters and disable the RSE projects filter
(In reply to Wim Jongman from comment #33) > 5. If your patch is included, close and open the project explorer > 6. See the PE filters and disable the RSE projects filter My change is not yet merged. How should it be included in that package?
(In reply to Matthias Becker from comment #34) > My change is not yet merged. How should it be included in that package? You don't have to. The fact is that there will be plugins in the workspace so using the filters will convince you. If you do want to run with your change then close down your regular Eclipse and let the jee eclipse point to your workspace and then run with that new target.
(In reply to Wim Jongman from comment #29) > (In reply to Matthias Becker from comment #27) > > Another question regarding my change: > > Is the location of the re-usable class EmptyWorkspaceHelper ok? > > Is it correct to put it into org.eclipse.ui.ide? > > I have put it into the org.eclipse.ui.views.navigator package which is API. > > Is this correct? Or is there a way where we can first provide it with > > "x-friends" to other eclipse plugins and later on (if needed) make "real" > > API? > > Ah, I did not catch that. I definitely should _not_ be API. I like the way > you have set it up but the class is not ready as API. > > > IMHO to become API: > > * It should not be final > * It should not implement all those listeners but use composition instead, > or even better, split it into two classes. One for the IDE with all the > listeners and one for the control/layout handling. > * Users should be able to provide their own empty control or override the > empty control creation. > * The automatic project creation empty page is specialized and should be a > subclass of the more abstract class. > * The empty part helper should move to JFace. > > Don't bother with x-friends unless that is required, which I don't hope. > This stuff is notorious for not being cleaned up. Done with the next patchset. I moved it into the new package org.eclipse.ui.internal.views.helpers and exposed this package to org.eclipse.jdt.ui and org.eclipse.ui.navigator via x-friends. Strange this I don't understand is: The ProjectExplorer class still get's an warning: "Discouraged access: The type 'EmptyWorkspaceHelper' is not API (restriction on required project 'org.eclipse.ui.ide')" but the PackageExplorerPart class does not. Can somebody explain?
(In reply to Wim Jongman from comment #32) > I'm afraid i do not ;) I think the trigger should not be how many projects > there are in the workspace but what the view is actually showing. If it is > empty it is empty and then the Empty...Helper ;) should kick in. The class is called Empty*Workspace*Helper for a reason. ;-) If we show that text in all cases when the view is empty what should the text say? "There are no projects in your workspace." definitely is wrong? Currently we know two situations: a) the user has explicitly filtered out projects. Should we then say: "You have filtered out everything"? And what should be the call to action? "Create a project" or "Adapt your filter"? A newly created project may be filtered out right away and the view still would show that text page. b) projects are filtered implicitly (like RSE does). What should we say in that case? "There are no visible projects in your workspace. Create projects....)? Wouldn't this "visible" word confuse users? And wouldn't this bring the focus on a hidden project that anyway should not be seen? So once again. The general "theme" of this bug is not to show such a huge amount of text in *any* view that is empty. I think it really would be contra-productive if a lot of views shows a lot of text. It would look overloaded. The purpose of this bug is about helping first-time user's of eclipse to find their first steps. Have a look at https://bugs.eclipse.org/bugs/attachment.cgi?id=277252 so how nicely VScode does this. They say "You have not yet opened a folder" and provide a button to open one. In the RSE case the user already did something after he has started his IDE for the first tim. He did switch to the RSE perspective and did create a system connection. When he now goes back to a perspective that includes e.g. the Project Explorer he sees an empty Project Explorer (just as it is until today). I would say it's ok in that case that we don't see the explanatory text. > Don't get me wrong. I love the concept you are bringing to Eclipse and I > think it should become part of the JFace Viewer framework: > > > TreeViewer viewer = new TreeViewer(parent, SWT.NONE); > viewer.setContentProvider(ArrayContentProvider.instance); > viewer.setLabelProvider(MyLabelProvider.instance); > viewer.setEmptyHelper(new EmptyWorkspaceHelper()); > > EmptyWorkSpaceHelper extends EmptyViewHelper implements > IPerspectiveListener I am not sure about making in part of JFace. I just made it re-usable because of the various ".. Explorer" views in Eclipse "Project Explorer", "Package Explorer" and "Navigator". But we can decide on this later on as (with my newest patchset) this class is not API and we can change it in later versions. > Having said all this. I am +1 if you want to push this now for M3 as an > incubation trial. Thanks for that.
Dani, Lars, Andrey, Thomas: What's your opinion ?
(In reply to Matthias Becker from comment #38) > Dani, Lars, Andrey, Thomas: What's your opinion ? I agree with your last comment 37. Make it easy for beginners is the main focus of this bug. RSE & co... is not. (In reply to Matthias Becker from comment #24) > (In reply to Wim Jongman from comment #23) > > Created attachment 277444 [details] > > No text when filters active > > > > This is what I see when there are filtered out projects. > > Works as designed. The explanatory text only appears when the workspace is > empty. > An empty project explorer because the user has filtered out all projects is > another use-case. Here the user proactively did something (configured a > filter). We should not mix the two. If we want to improve the UI also in > these cases we should address this in a separate bugzilla. Also agree with that. Let do a first step and improve in the next iteration. Proposed change is already a good improvement for many users. In the next patch we can address other use cases.
(In reply to Andrey Loskutov from comment #39) > Also agree with that. Let do a first step and improve in the next iteration. > Proposed change is already a good improvement for many users. In the next > patch we can address other use cases. I prefer incremental improvements over initial perfection so +1 for the current change (note: I did not look at the code, but the screenshot of Matthias look very useful for new users).
(In reply to Matthias Becker from comment #37) > The class is called Empty*Workspace*Helper for a reason. ;-) Yes because to serve your specific use case. My point is that you have solved something that I think is a general (so far unnamed) UI pattern. When I saw your changes it hit me that no tree or list or table or combobox should be shown empty to the user. The UI pattern is that users should always be helped on its way to solving that situation. I will attach an example of other uses of this pattern.
(In reply to Wim Jongman from comment #41) > > I will attach an example of other uses of this pattern. I have file bug 544226 instead.
(In reply to Wim Jongman from comment #42) > (In reply to Wim Jongman from comment #41) > > > > > I will attach an example of other uses of this pattern. > > I have file bug 544226 instead. Wim, what about original patch https://git.eclipse.org/r/135629? Can it be merged now or do you think we should first implement bug 544226 and after that update the patch on top of new bug 544226 code?
(In reply to Andrey Loskutov from comment #43) > > Can it be merged now Yes, merge it now. 544226 is a follow-up.
Gerrit change https://git.eclipse.org/r/135629 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=58942df4c699498939dc1a0bf85d80839031fc09
New Gerrit change created: https://git.eclipse.org/r/136493
(In reply to Eclipse Genie from comment #46) > New Gerrit change created: https://git.eclipse.org/r/136493 Thank you Andrey and all the others that have given fast and good feedback. I just also added a New-And-Noteworthy Entry.
Gerrit change https://git.eclipse.org/r/136493 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=01f764c6656544e6486c0b670799d6a113a94010
(In reply to Matthias Becker from comment #47) > Thank you Andrey and all the others that have given fast and good feedback. > I just also added a New-And-Noteworthy Entry. For the N&N I suggest to use the Java perspective as example. The plug-in perspective as used now in the screenshot is IMHO not the standard use case.
I just stumbled upon this ticket and would like to thank and congratulate Matthias and others for this extremely good addition to the IDE!
(In reply to Mickael Istria from comment #50) > I just stumbled upon this ticket and would like to thank and congratulate > Matthias and others for this extremely good addition to the IDE! +1 this is a kick-ass UX improvement. Thanks, Matthias for triggering this and Andrey for the detailed review.
(In reply to Lars Vogel from comment #49) > (In reply to Matthias Becker from comment #47) > > Thank you Andrey and all the others that have given fast and good feedback. > > I just also added a New-And-Noteworthy Entry. > > For the N&N I suggest to use the Java perspective as example. The plug-in > perspective as used now in the screenshot is IMHO not the standard use case. This can be done after we merge the fix for JDT UI, which is still pending, because we need SDK build first to get error free JDT UI Gerrit.
(In reply to Andrey Loskutov from comment #52) > This can be done after we merge the fix for JDT UI, which is still pending, > because we need SDK build first to get error free JDT UI Gerrit. Please add link to the bug to this one. AFAICS in this bug, nothing is open.
(In reply to Lars Vogel from comment #53) > (In reply to Andrey Loskutov from comment #52) > > This can be done after we merge the fix for JDT UI, which is still pending, > > because we need SDK build first to get error free JDT UI Gerrit. > > Please add link to the bug to this one. AFAICS in this bug, nothing is open. https://git.eclipse.org/r/#/c/136279/ and bug 544142.
(In reply to Wim Jongman from comment #41) > My point is that you have solved something that I think is a general >(so far unnamed) UI pattern. This patter is called "user onboarding". It's used everywhere: in computer games, mobile phone setup, ... Let's use the term "user onboarding" when discussing about this pattern.
(In reply to Matthias Becker from comment #22) > I removed the "import project" option from the list of available options. > The purpose of this text is to on-board new / occasional users. These user > typically won't import projects from git / from a zip / from the hard disk. I disagree here. Think about an employee setting up a new laptop, environment, joining a new existing team, trying Eclipse IDE coming from another IDE... In all those cases, the user has project pre-existing to the IDE. Actually, it's also a constant of the domain: there are much more project "maintained" (ie code pre-exist to the user and the tool) than project created from scratch. Please re-add the Import Projects link.
(In reply to Mickael Istria from comment #56) > (In reply to Matthias Becker from comment #22) > > I removed the "import project" option from the list of available options. > > The purpose of this text is to on-board new / occasional users. These user > > typically won't import projects from git / from a zip / from the hard disk. > > I disagree here. > Think about an employee setting up a new laptop, environment, joining a new > existing team, trying Eclipse IDE coming from another IDE... In all those > cases, the user has project pre-existing to the IDE. Actually, it's also a > constant of the domain: there are much more project "maintained" (ie code > pre-exist to the user and the tool) than project created from scratch. > Please re-add the Import Projects link. +1
(In reply to Lars Vogel from comment #57) > (In reply to Mickael Istria from comment #56) > > (In reply to Matthias Becker from comment #22) > > > I removed the "import project" option from the list of available options. > > > The purpose of this text is to on-board new / occasional users. These user > > > typically won't import projects from git / from a zip / from the hard disk. > > > > I disagree here. > > Think about an employee setting up a new laptop, environment, joining a new > > existing team, trying Eclipse IDE coming from another IDE... In all those > > cases, the user has project pre-existing to the IDE. Actually, it's also a > > constant of the domain: there are much more project "maintained" (ie code > > pre-exist to the user and the tool) than project created from scratch. > > Please re-add the Import Projects link. > > +1 +1 When opening up a fresh workspace I would quite often import existing projects (from file and from Git), as well as starting a new project. Also, well done! This is a welcome new feature.
(In reply to Mickael Istria from comment #56) > (In reply to Matthias Becker from comment #22) > > I removed the "import project" option from the list of available options. > > The purpose of this text is to on-board new / occasional users. These user > > typically won't import projects from git / from a zip / from the hard disk. > > I disagree here. > Think about an employee setting up a new laptop, environment, joining a new > existing team, trying Eclipse IDE coming from another IDE... In all those > cases, the user has project pre-existing to the IDE. Actually, it's also a > constant of the domain: there are much more project "maintained" (ie code > pre-exist to the user and the tool) than project created from scratch. > Please re-add the Import Projects link. Let's discuss this in a new bugzilla. The "import" link also had some additional flaws. My implementation did open the "import existing projects into workpace" wizard which is only *one* way to import existing projects. Today one would most likely import project a project from a git repo (which would not be covered by this wizard). Another possibility would be to open the generic "Import" wizard. But this wizard also gives the possibility to import other stuff (e.g. preferences) then projects. Best way would be to open the import wizard and have it filtered to only wizards that can import projects. So you see there is more to discuss on this topic. That's the reason why I propose to handle this in a new bugzilla.
(In reply to Matthias Becker from comment #59) > Today one would most likely import project a > project from a git repo (which would not be covered by this wizard). I don't agree neither. Many users already have their Git workspace locally, especially if they come from other tools, and many users who do have Git repos don't use the Git specific import wizard (they just import the "folder" and EGit may automatically detect the repo). > Another possibility would be to open the generic "Import" wizard. But this > wizard also gives the possibility to import other stuff (e.g. preferences) > then projects. Best way would be to open the import wizard and have it > filtered to only wizards that can import projects. While I agree with you about the ideal scenario, I think it's far from being a blocker compared to the value of making import wizard accessible from empty Project Explorer. We could just call the link "Import..." and show the "composite" import wizard. While not everything are projects, it does enable what's most likely expected from onboarding users; while not having a visible import workflow feels missing and worrying for new users ("is Eclipse IDE only able to deal with new code?")
New Gerrit change created: https://git.eclipse.org/r/136526
(In reply to Eclipse Genie from comment #61) > New Gerrit change created: https://git.eclipse.org/r/136526 That's my implementation of comment 60
Created attachment 277516 [details] After my patch from comment 61 (with perspective specific project wizards)
Created attachment 277517 [details] After my patch from comment 61 (without perspective specific project wizards - in Resource Perspective)
Created attachment 277518 [details] After my patch from comment 61 (without perspective specific project wizards - e.g. in Resource Perspective) Pls. ignore the previous screenshot. I picked the wrong one.
Gerrit change https://git.eclipse.org/r/136526 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2b2ef0afd2c748a2fdc0c69544c257f5812e69d1
Two issues: 1. The user has no clue what 'Create other...' would do. ==> use 'Create new project' 2. It's not clear why one link has "..." and other don't. Ideally we would replace 'Create
(In reply to Dani Megert from comment #67) > Two issues: > 1. The user has no clue what 'Create other...' would do. > ==> use 'Create new project' > 2. It's not clear why one link has "..." and other don't. > > Ideally we would replace 'Create Sorry, wasn't done yet. I just went ahead and fixed the labels: "Create other..." --> "Create new project..." "Import projects" --> "Import projects..." Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=eaf49f82571a0caa3380fca6e70a1b07ff9e06b3
Just found out that pasting code snippets into the Package Explorer and Project Explorer is broken. I've reverted the change in the Package Explorer. I will wait to revert that change to find a fix. I've no fix is in by next Friday I will also revert this change.
(In reply to Dani Megert from comment #69) > Just found out that pasting code snippets into the Package Explorer and > Project Explorer is broken. I've reverted the change in the Package > Explorer. I will wait to revert that change to find a fix. I've no fix is in > by next Friday I will also revert this change. I've no fix is in -> *If* no fix is in
New Gerrit change created: https://git.eclipse.org/r/136623
Gerrit change https://git.eclipse.org/r/136623 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=80b6b0a7a778bcdfdbed0fbf6b39d8b2626df3fb
(In reply to Eclipse Genie from comment #72) > Gerrit change https://git.eclipse.org/r/136623 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=80b6b0a7a778bcdfdbed0fbf6b39d8b2626df3fb > This does not work. Tried with eclipse-SDK-I20190210-2135-win32-x86_64. 1. Start with new workspace 2. Close Welcome page 3. Window > Show View > Project Explorer ==> - Ctrl+Insert and Ctrl+V don't work - Edit > Paste is disabled - context menu in view is not available hence context menu > Paste not available NOTE: In 4.10 the first two items are also not working (until there was at least one project created and deleted again). However, one could use the third option. Please either provide a fix or revert the change until a fix is available. Thanks.
(In reply to Dani Megert from comment #73) > - context menu in view is not available hence context menu > Paste not > available This is a new requirement: show a context menu of the original "full featured" widget for the "empty" one. If we want support this, we should create a dedicated bug and discuss there. I've "hacked" a quick and dirty solution locally, but it is too dirty, and I see that for a "full featured" support of the original context menu we need probably new API here. The question for me is: does it make sense have such a "full" menu in an "empty" widget at all? If you look on the original Package Explorer, most of the menu entries (I would say all except "Paste") do not make sense for the "empty" state or have found their *better* replacement in the new actions list, and "Paste" functionality (while very useful from SDK developers point of view) is also very surprising for anyone not aware about JDT internals. > NOTE: In 4.10 the first two items are also not working (until there was at > least one project created and deleted again). However, one could use the > third option. Please note, that if you use SDK and default Java perspective, you still have the "Paste" Ctrl+C shortcut in Package Explorer, which allows you to use the "Paste" feature without a context menu. So for experienced JDT developers the "usual" working model with "Paste" creating new compilation units is still supported. However, I doubt that new users will miss the "Paste" menu with the hidden JDT feature. > Please either provide a fix or revert the change until a fix is available. Please consider to not revert: 1) The old working model is still supported by Package Explorer. 2) The main target audience of the "Empty workspace helper" is not affected by a missing menu. 3) The benefits of having an easy to discover "user onboarding" in IDE far outweigh the found regression.
(In reply to Andrey Loskutov from comment #74) > (In reply to Dani Megert from comment #73) > > - context menu in view is not available hence context menu > Paste not > > available > > This is a new requirement: show a context menu of the original "full > featured" widget for the "empty" one. If we want support this, we should > create a dedicated bug and discuss there. No. This is not a new feature but one that was there and got broken. > I've "hacked" a quick and dirty solution locally, but it is too dirty, and I > see that for a "full featured" support of the original context menu we need > probably new API here. Could well be, but might be overkill. > The question for me is: does it make sense have such a "full" menu in an > "empty" widget at all? Yes. It's a workflow that users are used to. Especially mouse users like me. > If you look on the original Package Explorer, most of the menu entries (I > would say all except "Paste") do not make sense for the "empty" state or > have found their *better* replacement in the new actions list, and "Paste" > functionality (while very useful from SDK developers point of view) is also > very surprising for anyone not aware about JDT internals. Show In can also be useful if one wants to switch to the Project Explorer in a new workspace. > Please note, that if you use SDK and default Java perspective, you still > have the "Paste" Ctrl+C shortcut in Package Explorer, which allows you to > use the "Paste" feature without a context menu. So for experienced JDT > developers the "usual" working model with "Paste" creating new compilation > units is still supported. Are you saying that mouse users are not experienced? ;-) > 2) The main target audience of the "Empty workspace helper" is not affected > by a missing menu. Sure, but the mouse user audience that used to use context menu > Paste is. How about this idea: We add another link that allows to paste the snippet, e.g. Create project from clipboard or Create project from snippet in clipboard. ? That would remove my concerns.
Did you consider to just reparent the context menu of the viewer to the context menu of the helper?
(In reply to Wim Jongman from comment #76) > Did you consider to just reparent the context menu of the viewer to the > context menu of the helper? Yes, this was what I've mentioned by a "quick and dirty" solution. However it was ugly, because in CommonNavigator you are creating menu at a different point in time as in Package Explorer, the menu had to be manually attached to an internal widget which we don't expose to clients yet, the menu must be updated on every perspective change, etc. If you see an elegant solution with reparenting, just push a patch for a review. (In reply to Dani Megert from comment #75) > How about this idea: We add another link that allows to paste the snippet, > e.g. > Create project from clipboard > or > Create project from snippet in clipboard. > ? That would remove my concerns. This would mean, we either contribute it to the "New" wizards (which is probably not make much sense?) or find a way to contribute it directly from clients to the helper instance. I have no bandwidth to work on this, sorry.
(In reply to Andrey Loskutov from comment #77) > This would mean, we either contribute it to the "New" wizards (which is > probably not make much sense?) or find a way to contribute it directly from > clients to the helper instance. > > I have no bandwidth to work on this, sorry. OK, then I will at least revert the Package Explorer changes as they are also dirty because they use internal code and I don't see hope that bug 544226 will be resolved for M3.
(In reply to Dani Megert from comment #73) > This does not work. Tried with eclipse-SDK-I20190210-2135-win32-x86_64. > 1. Start with new workspace > 2. Close Welcome page > 3. Window > Show View > Project Explorer > ==> > - Ctrl+Insert and Ctrl+V don't work > - Edit > Paste is disabled > - context menu in view is not available hence context menu > Paste not > available > > NOTE: In 4.10 the first two items are also not working (until there was at > least one project created and deleted again). Filed bug 544349 for that old bug.
(In reply to Dani Megert from comment #78) > I don't see hope that bug 544226 will be resolved for M3. That one has not been assigned. I expect Matthias wants to work on this.
(In reply to Wim Jongman from comment #80) > (In reply to Dani Megert from comment #78) > > > I don't see hope that bug 544226 will be resolved for M3. > > That one has not been assigned. I expect Matthias wants to work on this. Hopefully yes, but I think he's away at least this week and next week is M3.
See bug 544443 for a case where the hints don't seem to work.
(In reply to Dani Megert from comment #78) > (In reply to Andrey Loskutov from comment #77) > > This would mean, we either contribute it to the "New" wizards (which is > > probably not make much sense?) or find a way to contribute it directly from > > clients to the helper instance. > > > > I have no bandwidth to work on this, sorry. > OK, then I will at least revert the Package Explorer changes as they are > also dirty because they use internal code For the records, I've not done this. We can polish during 4.12.
New Gerrit change created: https://git.eclipse.org/r/137083
Gerrit change https://git.eclipse.org/r/137083 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=1e35ed0ff2dd5c54aa9898499687a0dfb21155e7
New Gerrit change created: https://git.eclipse.org/r/137132
(In reply to Lars Vogel from comment #49) > (In reply to Matthias Becker from comment #47) > > Thank you Andrey and all the others that have given fast and good feedback. > > I just also added a New-And-Noteworthy Entry. > > For the N&N I suggest to use the Java perspective as example. The plug-in > perspective as used now in the screenshot is IMHO not the standard use case. Done with https://git.eclipse.org/r/#/c/137132/
Gerrit change https://git.eclipse.org/r/137132 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=529915b9960effc3054eb8d97d3a13f4ec3feb7e
so what is still to be done to set this bug zu "fixed"?
(In reply to Matthias Becker from comment #89) > so what is still to be done to set this bug zu "fixed"? There are some memory leaks in EmptyWorkspaceHelper. The images created with ImageDescriptor.createImage are never disposed of.
(In reply to Wim Jongman from comment #90) > (In reply to Matthias Becker from comment #89) > > so what is still to be done to set this bug zu "fixed"? > > There are some memory leaks in EmptyWorkspaceHelper. The images created with > ImageDescriptor.createImage are never disposed of. Okay I will have a look at this. You say "some" what are the other leaks?
New Gerrit change created: https://git.eclipse.org/r/137177
(In reply to Eclipse Genie from comment #92) > New Gerrit change created: https://git.eclipse.org/r/137177 This fixes the missing disposal of the images. Wim, can you pls. review?
Mass change, please reset target if you still planning to fix this for 4.11.
(In reply to Dani Megert from comment #75) > How about this idea: We add another link that allows to paste the snippet, Good idea but it's too prominent for the onboarding page. This should really only contain the "most important" actions. If we put in there too much it will overwhelm users - less is more in this context. I would propose to add a context menu to the onboarding page instead. That context menu should contain all the "not so important" actions. I would add "paste" to the context menu. Another topic: What about "Refresh"? I just copied a project folder into the workspace folder in my file explorer. Eclipse does not automatically refresh so I have to manually refresh the project explorer. So should we also add refresh to the context menu?
(In reply to Matthias Becker from comment #91) > You say "some" what are the other leaks? createImage is used in multiple places. I noticed because I took out helper as base for 544226
(In reply to Wim Jongman from comment #96) > (In reply to Matthias Becker from comment #91) > > > You say "some" what are the other leaks? > > createImage is used in multiple places. I noticed because I took out helper > as base for 544226 I think I fixed all of them. Can you pls. review my change?
(In reply to Matthias Becker from comment #95) > I would propose to add a context menu to the onboarding page instead. That > context menu should contain all the "not so important" actions. I would add > "paste" to the context menu. Fine with me. > Another topic: What about "Refresh"? > I just copied a project folder into the workspace folder in my file > explorer. Eclipse does not automatically refresh so I have to manually > refresh the project explorer. So should we also add refresh to the context > menu? Yes, that's why it was there before ;-). Also, pressing F5 (or whatever is bound to the Refresh command) should refresh. I would suggest that we close this for M3 and create new bugs for the further work, depending on this.
Java Browsing Perspective - Projects view also can have some assistance ( not a must) Git Perspective - Assistance existed before adding others but now locations appear to be inconsistent. Git Perspective has it in middle of the view where as the newly added ones are there in the top.
(In reply to Sarika Sinha from comment #99) > Git Perspective - Assistance existed before adding others but now locations > appear to be inconsistent. Git Perspective has it in middle of the view > where as the newly added ones are there in the top. see https://bugs.eclipse.org/bugs/show_bug.cgi?id=544277
(In reply to Matthias Becker from comment #100) > (In reply to Sarika Sinha from comment #99) > > Git Perspective - Assistance existed before adding others but now locations > > appear to be inconsistent. Git Perspective has it in middle of the view > > where as the newly added ones are there in the top. > > see https://bugs.eclipse.org/bugs/show_bug.cgi?id=544277 Great!
(In reply to Dani Megert from comment #98) > (In reply to Matthias Becker from comment #95) > > I would propose to add a context menu to the onboarding page instead. That > > context menu should contain all the "not so important" actions. I would add > > "paste" to the context menu. > Fine with me. > > > > Another topic: What about "Refresh"? > > I just copied a project folder into the workspace folder in my file > > explorer. Eclipse does not automatically refresh so I have to manually > > refresh the project explorer. So should we also add refresh to the context > > menu? > Yes, that's why it was there before ;-). Also, pressing F5 (or whatever is > bound to the Refresh command) should refresh. > > > I would suggest that we close this for M3 and create new bugs for the > further work, depending on this. That sounds reasonable. Let's keep this bug open until we have fixed the leaked images and create a new one for the context menu and the Refresh-Shortcut.
I think it's too late for https://git.eclipse.org/r/#/c/137177/ to go into M3. Correct? Can I merge it anyway so that it goes into the next RC?
(In reply to Matthias Becker from comment #103) > I think it's too late for https://git.eclipse.org/r/#/c/137177/ to go into > M3. Correct? > > Can I merge it anyway so that it goes into the next RC? I suggest to merge it so that a potential rebuild picks it up for M3.
Gerrit change https://git.eclipse.org/r/137177 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0157869c682cf7140b7faec07b22c2229ce444b4
(In reply to Lars Vogel from comment #104) > (In reply to Matthias Becker from comment #103) > > I think it's too late for https://git.eclipse.org/r/#/c/137177/ to go into > > M3. Correct? > > > > Can I merge it anyway so that it goes into the next RC? > > I suggest to merge it so that a potential rebuild picks it up for M3. +1
The image should be no more than 520 pixels wide. I will update it while editing the N&N entry. See https://www.eclipse.org/eclipse/news/instructions.html for general N&N instructions.
(In reply to Noopur Gupta from comment #107) > The image should be no more than 520 pixels wide. I will update it while > editing the N&N entry. > > See https://www.eclipse.org/eclipse/news/instructions.html for general N&N > instructions. Would it be sufficient to change the "width" attribute of the img-tag? Via this the browser would scale down the image and it would stay crisp.
New Gerrit change created: https://git.eclipse.org/r/137360
Gerrit change https://git.eclipse.org/r/137360 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=ead4b9878ef8695cc019f96077db20ab97b53909
(In reply to Wim Jongman from comment #32) > [...] I think the trigger should not be how many projects > there are in the workspace but what the view is actually showing. If it is > empty it is empty and then the Empty...Helper ;) should kick in... Apparently it's late but I must absolutely second this. I just found out that this new EmptyWorkspaceHelper completely breaks contributions of "virtual projects" to the Project Explorer, such as CDO Checkouts. A CDO user complained that CDO Checkouts are no longer functional at all: https://www.eclipse.org/forums/index.php/mv/msg/1101335/1817172/#msg_1817172 . I didn't realize the problem earlier because in our test workspaces there are always a few real projects, as well. Wim is absolutely correct in that the Project Explorer, which is fundamentally based on the Common Navigator's pluggable content contribution system, the concept of emptiness must not be determined purely on the basis of a single contribution type. As I have no means to impact this emptiness detection from outside the Project Explorer I must ask you to fix this problem in it or remove the EmptyWorkspaceHelper altogether. Do you suggest that I open a new bugzilla?
Eike, please open a new bug and if possible provide a Gerrit for the fix. -1 for removal
(In reply to Eike Stepper from comment #111) > remove the EmptyWorkspaceHelper altogether. EmptyWorkspaceHelper is a nice to have that's working perfectly in a majority of cases. A non-functional EmptyWorkspaceHelper (because of hidden/virtual project) is not at all a usability regression, it's just a missing nice-to-have; and doesn't induce any bug nor strong confusion. So there is no valid reason to remove it IMO. Improving it would still be welcome.
(In reply to Mickael Istria from comment #113) > EmptyWorkspaceHelper is a nice to have I agree. > that's working perfectly in a majority of cases. This is a bogus statement. How do you judge what "working perfectly" and what exactly "a majority of cases" is? In particular, how can you establish that it's working perfectly, when several people have demonstrated that this new functionality breaks clients of the framework that evidently used to work perfectly within the boundaries of the specified public API for more than a decade?! > A non-functional EmptyWorkspaceHelper (because of > hidden/virtual project) is not at all a usability regression, it's just a > missing nice-to-have; and doesn't induce any bug nor strong confusion. Sorry, I can not understand what this sentence means. Clearly the current behavior of the EmptyWorkspaceHelper is a major usability regression for some clients. And these clients can do absolutely nothing about it. > So there is no valid reason to remove it IMO. I totally agree in that it's a very nice feature to give hints to users who sit in front of an empty Project Explorer and have no idea what to do with it. Note that this is, as Wim pointed out very early, purely a UI-level problem. The Project Explorer is a facility that visually pulls together and presents information that can be contributed from various phyical sources. All visual functions of the Project Explorer must be designed and evolved with this fundamental paradigm in mind. So we're clearly talking about a regression. What I really don't get is how all expressed and due concerns are wiped away just because nobody could find a satisfactory answer to the simple question "what should the text say?" (see comment #37). Again, I think the original intent to guide the new user is valid and good. But the way the discussion about the implementation details unfolds is not okay. You just can not take away granted functionality and break an unknown number of client technologies and their users. And then, when they complain, you argue they're not the majority, so it's all acceptable. > Improving it would still be welcome. I read this as "Please fix the problem that we've introduced yourself". Great! Is that what "Let do a first step and improve in the next iteration. Proposed change is already a good improvement for many users." (comment #39) or "I prefer incremental improvements over initial perfection" (comment #40) had in mind?
Eike, sorry for my confusion, I misunderstood the problem by reading too fast (I thought it was an occurence "EmptyWorkspaceHelper not visible", while it's actually "EmptyWorkspaceHelper hides payload content"). I agree it's a major regression, and that it can qualifies as worth being disabled by default.
This feature has been delivered in 4.11, hence this must remain closed. Please track any regressions in new bugs.
(In reply to Mickael Istria from comment #115) > Eike, sorry for my confusion, I misunderstood the problem by reading too > fast (I thought it was an occurence "EmptyWorkspaceHelper not visible", > while it's actually "EmptyWorkspaceHelper hides payload content"). > I agree it's a major regression, I'm very glad that we agree now ;-) > and that it can qualifies as worth being > disabled by default. I think disabling it or even removing it is not necessary. As we all seem to agree the new functionality "give hints on empty view" is a very nice to have. I think it can be improved to make everybody happy and I'm currently working on a Gerrit patch. The subtleties of the CNF make it a little harder, though. But I'm in the process of finding a solution. Stay tuned...
As already said: please handle this in a new bug report. Thanks.
Great to have this discussion after https://bugs.eclipse.org/bugs/show_bug.cgi?id=543746#c112 just to reach the same conclusion as in https://bugs.eclipse.org/bugs/show_bug.cgi?id=543746#c112 ;-)
I've submitted bug 553353 to track the issue.
(In reply to Eike Stepper from comment #120) > I've submitted bug 553353 to track the issue. Thanks Eike!
