Community
Participate
Working Groups
The name "workspace" is very generic, and it's very possible that some user who's not familiar with Eclipse doesn't understand what it is about, and deletes it by lack of context. Rather than just "workspace", we could image the default workspace called "${productName}_workspace", such as "eclipse_workspace" or "rhdevstudio_workspace".
New Gerrit change created: https://git.eclipse.org/r/81964
Set tentative target to 4.7.M3.
+1 from my side, adding Dani, so he can give feedback.
(In reply to Mickael Istria from comment #0) > The name "workspace" is very generic, and it's very possible that some user > who's not familiar with Eclipse doesn't understand what it is about, and > deletes it by lack of context. > Rather than just "workspace", we could image the default workspace called > "${productName}_workspace", such as "eclipse_workspace" or > "rhdevstudio_workspace". Using the product name (or ID) could work in a static environment, but that's not what we have. If a user starts with Platform download, then installs e.g. the full SDK, then it would not restart with the existing Platform workspace but create a new one for the SDK product. Definitely not something the user expects. Another problem is that the product name can contain characters that aren't allowed on a certain OS. ==> -1 from me for this.
(In reply to Dani Megert from comment #4) > Using the product name (or ID) could work in a static environment, but > that's not what we have. If a user starts with Platform download, then > installs e.g. the full SDK, then it would not restart with the existing > Platform workspace but create a new one for the SDK product. Definitely not > something the user expects. If I read the code correctly, the proposal I made via Gerrit only change the very first proposal, before the preferences for "known workspaces" is set. When a workspace is already known by the application, it's this one which gets suggested by default. So in the scenario you mention, it would create a workspace, store this workspace as "known" in the preferences, then user install the SDK, restarts, and the workspace dialog shows the same workspace as it's known. > Another problem is that the product name can contain characters that aren't > allowed on a certain OS. In the patch, I've used the launcher name which should be made of valid characters.
(In reply to Mickael Istria from comment #5) > If I read the code correctly, the proposal I made via Gerrit only change the > very first proposal, before the preferences for "known workspaces" is set. > When a workspace is already known by the application, it's this one which > gets suggested by default. > So in the scenario you mention, it would create a workspace, store this > workspace as "known" in the preferences, then user install the SDK, > restarts, and the workspace dialog shows the same workspace as it's known. > > > Another problem is that the product name can contain characters that aren't > > allowed on a certain OS. > > In the patch, I've used the launcher name which should be made of valid > characters. I did not do any code review, but just commented based on what is mentioned in this bug report - this should be enough. Maybe you need to update the summary and clarify your initial comment.
Using '_' might not looks so good. '-' might be better.
(In reply to Dani Megert from comment #7) > Using '_' might not looks so good. '-' might be better. OK, I'll update summary and patch.
I like this proposal a lot! Thanks Mickael for suggesting this!
If we're going to auto-generate this workspace location, which I think is a good thing generally, then we should ensure we put the workspace in the OS-specified application data locations: OS X: @user.home/Library/Application Support/<<product>> Windows: @user.home/@user.home/Application Data/<<product>> Linux: @user.home/.config/shared/<<product>> That should be true across everything we do (including the ~/.eclipse directory).
(In reply to Brian de Alwis from comment #10) > If we're going to auto-generate this workspace location The proposal include no change regarding how and when the workspace is generated, it's just about making another proposal as default directory name, but still in the same folder as it is now. Maybe your comment is more related to bug 502219 ?
EquinoxLocation, line 97 seems to also require a change. As it's another component, should I open another bug?
New Gerrit change created: https://git.eclipse.org/r/82369
@Thomas: do you see any issue with this proposal and patch? Anything I could do to improve the chances to have this in M4?
(In reply to Mickael Istria from comment #14) > @Thomas: do you see any issue with this proposal and patch? Anything I could > do to improve the chances to have this in M4? I have a open question on the gerrit review. On windows the folder name will contain the launcher extension '.exe'. That looks odd, is that intended?
(In reply to Thomas Watson from comment #15) > (In reply to Mickael Istria from comment #14) > > @Thomas: do you see any issue with this proposal and patch? Anything I could > > do to improve the chances to have this in M4? > > I have a open question on the gerrit review. On windows the folder name > will contain the launcher extension '.exe'. That looks odd, is that > intended? Mickael, what do you think about the windows folder name?
(In reply to Thomas Watson from comment #16) > Mickael, what do you think about the windows folder name? It's indeed an issue, however, my priorities have evolved and I cannot commit to work on it soon.
(In reply to Thomas Watson from comment #16) > Mickael, what do you think about the windows folder name? Last version of patch set should improve it (although I couldn't fully test it as I don't have Windows).
Gerrit change https://git.eclipse.org/r/82369 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=60a423633ebd7246d33e8f95eb642e1dbeb2ea07
Mickael, please add to the N&N M7.
(In reply to Lars Vogel from comment #20) > Mickael, please add to the N&N M7. Can someone explain me why this change was needed? See Thomas comment on the merged patch: "The default for the Eclipse SDK download has this set in the config.ini already so the changes here will have not impact on the default value: osgi.instance.area.default=@user.home/workspace" Is this only for products that do not specify their osgi.instance.area.default value?
(In reply to Andrey Loskutov from comment #21) > (In reply to Lars Vogel from comment #20) > > Mickael, please add to the N&N M7. > > Can someone explain me why this change was needed? See Thomas comment on the > merged patch: > "The default for the Eclipse SDK download has this set in the config.ini > already so the changes here will have not impact on the default value: > osgi.instance.area.default=@user.home/workspace" Confirmed. Just tested with the Eclipse SDK and it uses C:\Users\<myLogin>\workspace
(In reply to Andrey Loskutov from comment #21) > Is this only for products that do not specify their > osgi.instance.area.default value? Indeed, only those that do not specify osgi.instance.area.default in their config.ini should be impacted by this change. The patch doesn't fully covers the user story mentioned initially. More changes would be necessary to cover the initial request. I cannot commit on doing more changes on this topic soon.
I'm beginning to think these in-code values for the default are a bad idea for the instance location. See bug 514333 for discussions on if we should have an option to disable the use of the in-code defaults. With that in mind is there really an important motivation for having this change to the in-code default? Why not just put your product name in the value in the config.ini? osgi.instance.area.default=eclipse-workspace
(In reply to Thomas Watson from comment #24) > Why not just put your product name in the > value in the config.ini? > > osgi.instance.area.default=eclipse-workspace Seems like that would be enough for the initial use-case. What would be great would be to have the config.ini generating this property with the ${launcherName}-value, but it's something for PDE I guess. Anyway, if this is causing trouble, I wouldn't mind to see the change reverted.
(In reply to Mickael Istria from comment #25) > Anyway, if this is causing trouble, I wouldn't mind to see the change > reverted. +1 to revert, since those EPPs who want the change the default have to touch the config.ini anyways. It's better they keep full control instead of relying on a yet other hard-coded convention. > What would be great would be to have the config.ini generating this property > with the ${launcherName}-value, but it's something for PDE I guess. As far as I know this is set by our Tycho builder. I suggest to open a new bugs for EPPs and Platform Releng to change the default.
> I suggest to open a new bugs for EPPs and Platform Releng to change the > default. Done for EPP with https://bugs.eclipse.org/bugs/show_bug.cgi?id=514502
New Gerrit change created: https://git.eclipse.org/r/94170
Gerrit change https://git.eclipse.org/r/94170 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=88536c09bca1b61f1a3e7ade8b3c0167315fe337
(In reply to Eclipse Genie from comment #29) > Gerrit change https://git.eclipse.org/r/94170 was merged to [master]. > Commit: > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/ > ?id=88536c09bca1b61f1a3e7ade8b3c0167315fe337 I reverted the change. Closing this as wontfix. Sorry for the turn around Mickael. Thanks for contributing to the discussion though.
(In reply to Thomas Watson from comment #30) > Sorry for the turn around This will lead us to a much better solution, no need to be sorry.
