|Re: [ide-dev] Resource Management thoughts|
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>
Reply-To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: Friday, 13 September, 2013 7:37 AM
To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Subject: Re: [ide-dev] Resource Management thoughts
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
Installation-level Preferences / User-level Preferences instead of (or in addition to) workspace-level Preferences.
We need an easier way to open / export / import / team-share / materialize a workspace.
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
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).