Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Resource Management thoughts

I also wanted to quickly point out this bug, which has some relevant and recent discussion:

There is an associated gerrit patch that I think is too breaking a change, but there are some ideas in there about what kind of UX changes could be made to improve these workflows.

I do think there is a very clear design difference between VS and Eclipse that would be hard to reconcile. Generally speaking VS requires explicit user action to add/remove files, while Eclipse by default lets the file system structure dictate what you see, with options to explicitly exclude or link other files that don't match the physical structure as the exception. I worry that if you try to present some hybrid of those approaches in Eclipse you will end up with a UI that is theoretically more flexible, but in practice even more confusing and unintuitive to work with than what we have today. Supporting import/export and improving the initial setup experience sounds like a good idea though.


From:        Doug Schaefer <dschaefer@xxxxxxx>
To:        Discussions about the IDE <ide-dev@xxxxxxxxxxx>,
Date:        09/13/2013 11:29 AM
Subject:        Re: [ide-dev] Resource Management thoughts
Sent by:        ide-dev-bounces@xxxxxxxxxxx

Quick one on the resources, I agree, I think the issue for the resources stuff is more a UX issue. It's just really hard to set up projects that way so few people do. A simple "Add File" menu item would go a long way. And have the Delete file give the option to not really delete just like it does with projects, and have it manage excludes. As examples…


From: <Oberhuber>, Martin <Martin.Oberhuber@xxxxxxxxxxxxx>
Discussions about the IDE <
Friday, 13 September, 2013 7:37 AM
Discussions about the IDE <
Re: [ide-dev] Resource Management thoughts

Hi Doug,
I think that on project level, with all the work that Serge Beauchamp has done, the Eclipse resource model is already flexible enough to accommodate anything you could do in other IDE’s. The concepts are
-          Resource Filters (hide stuff under project root by default)
-          Project-relative linked resources (pull in stuff outside my project)
-          Virtual folders (group items).
It just isn’t leveraged today because by default, an Eclipse projects still pull in the stuff under its root and linked resources are not widely used.
The concept that’s currently missing is what you call “Solutions”. At Eclipse,
-          A Team Project Set is what you describe from a CM point of view, but
o   I cannot double click a team project set to open it.
o   And once imported, it isn’t visible any more as an item to operate on (“update all”, “close”, “switch”).
-          Working Sets nicely group projects inside a workspace, but
o   I cannot import/export team-share them easily
o   Newly added projects are not added to the working set automatically
-          A workspace is what you describe (group of projects to manage together), but
o   I cannot team-shared it easily,
o   I cannot double click to open it;
o   It isn’t a single item to run global operations easily (eg “update all”)
o   It is both project list + Preferences, but those two concepts should really be separate.
o   There is not good concept for “installation-level preferences” versus “workspace-level preferences”.
If I’m not mistaken, some of the Eclipse distros (eg Yoxos, Pulse) are addressing the 2nd problem by making it possible to materialize a workspace out of CM, and manage preferences and project list separately. Still these concepts are not quite as easy to use as they should be.
Personally, I think that your “solution” would best map to an Eclipse “Workspace” (eg only one solution is open at any one time). Remaining work is
-          We need Installation-level Preferences / User-level Preferences instead of (or in addition to) workspace-level Preferences.
John Arthorne once said that the association of the osgi.instance.are with the Resources IWorkspace is actually not too tight and it might be possible to tear those two apart, thus solving part of the problem. This problem is also related to supporting multiple workspaces inside one Eclipse instance.

-          We need an easier way to open / export / import / team-share / materialize a workspace.
A while ago I filed this bug for that:
FYI, there is still a whole lot of great links and ideas collected here from our previous discussions:
I believe some of those ideas are actually implemented by now (variables in linked resources, virtual folders) whereas other ideas are still very relevant.

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6
From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Thursday, September 12, 2013 10:35 PM
[ide-dev] Resource Management thoughts

Hey gang,
As an early part of e4, we talked about flexible resources as a thing. In particular, coming from other IDEs, it's pretty frustrating that Eclipse doesn't have the concept of "Solution"s, to steal the Visual Studio term, or projects that have a mapping from physical file to virtual folder layout you'd see in the project navigator.
Now, this comes up since I just ran into it. One of our developers just added a new plug-in and when I did a git pull, I ended up with lots of errors because I forgot to import that plug-in. Luckily I had a head up to know it was coming and I've seen this happen so many times, I know where to go look.
In another activity, I'm also looking at how we'd import projects from other IDEs into Eclipse, something that the CDT community has desired for quite some time. And that's made harder because the projects in those IDEs look a lot different than Eclipse because of this virtual mapping.
Question: is this a need you've seen as well. Should we reopen the flexible resources so we can do this right, assuming the capabilities aren't there (which I have a feeling some of this was done but not publicized well).
ide-dev mailing list

Back to the top