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.
Doug Schaefer <dschaefer@xxxxxxx>
Discussions about the
09/13/2013 11:29 AM
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â
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,
cannot double click a team project set to open it.
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
cannot import/export team-share them easily
added projects are not added to the working set automatically
A workspace is what you describe (group of projects to manage together),
cannot team-shared it easily,
cannot double click to open it;
isnât a single item to run global operations easily (eg âupdate allâ)
is both project list + Preferences, but those two concepts should really
is not good concept for âinstallation-level preferencesâ versus âworkspace-level
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. https://bugs.eclipse.org/bugs/show_bug.cgi?id=70683 https://bugs.eclipse.org/bugs/show_bug.cgi?id=245399
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).