Eclipse's "Workspaces" (Was: What you use D for?)

[David Gileadi]

Nick Sabalausky wrote:
> "Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
> news:g0qhir$v5v$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> Secondly, being from the Java world, Eclipse follows the (misguided, IMO) 
>>> Java philosophy of marrying its self with the filesystem. "A workspace 
>>> contains projects and projects contain sources, therefore workspaces and 
>>> projects should be folders, not files." Yea, well, the problem is that's 
>>> forcefully imposing an arbitrary choice.
>>>
>>> If I want to follow a convention of projects and workspaces being 
>>> folders, I can already do that with VS-style projects and workspaces. I 
>>> make a folder for the workspace, stick a workspace file named 
>>> ".workspace" in there, make subfolders for the projects, stick project 
>>> files named ".project" in those, etc. True, in that case, projects and 
>>> workspaces aren't *really* folders, they're each a folder *and* a file, 
>>> but Eclipse already has to do that anyway.
>>>
>>> You can *kinda* work around this in Eclipse with "Create Project From 
>>> Existing Source", but there are still limitations (a project and 
>>> workspace can't occupy the same directory - which breaks my usual style 
>>> of sticking the project and workspace files next to each other in the 
>>> top-level of a "MyProgram" directory).
>> If that's the case then you're probably misunderstanding the point of 
>> workspaces and making thm too small in scope. For example, I use a single 
>> workspace for all my projects (well, two; I always use Descent as an 
>> Eclipse runtime).
>>
>>> Plus, switching workspaces makes the entire Eclipse program reload (slow, 
>>> and why, for instance, should the help window close when I load a 
>>> different workspace?)
>>>
>>> Also, Eclipse seems to marry the ideas of "user settings" together with 
>>> that of "workspace". For instance, there are some settings, like syntax 
>>> coloring settings and "Open Associated Perspective: Remember my 
>>> decision", that are associated with a workspace, but should be treated as 
>>> global user settings (or at least, global within the scope of a user 
>>> account).
>>>
>>> Now if Eclipse had a notion of "Targets" (like CodeWarrior, IIRC) that 
>>> were children of projects, and contained the source files, then that 
>>> would solve most of my problems with Eclipse's workspaces, because then I 
>>> could treat a "Workspace" as container for user settings, and treat "A 
>>> project with target(s)" as alternate terminology for VS.NET's "A solution 
>>> with project(s)". But as far as I can tell, Eclipse doesn't seem to have 
>>> this.
>> I think you're tying the "workspace" to the "project" too closely. Visual 
>> Studio tends to associate those two concepts. In Eclipse, "workspace" and 
>> "user" are tied together, as there rarely seems to be any need to have 
>> multiple workspaces per user.
> 
> If that's the case then I'd argue Eclipse's concept of a "project" is too 
> limited/narrow (Unless it allows nested projects?).
> 
> Many times, I'll be working on some development project (that is, a 
> "project" in the everyday english sense of the word, not an IDE concept of 
> "project") that consists of more than one separate but related targets. Each 
> target will have its own set of sources. For example, there might be:
> 
> - "My Application"
> - A tool/utility or two that are specific to "My Application"
> - A library of functionality shared between the main app and the 
> app-specific tools/utils
> - A sample plugin to test/demonstrate "My Application"'s plugin mechanism
> 
> And there may be some other totally unrelated "My Other Application" that 
> has similar complexity.
> 
> So, that means there are a few requirements (all somewhat interrelated):
> 
> ------------
> 1.
> 
> There needs to be a three-level hierarchy that, regardless of terminology, 
> boils down to:
> 
> "Group of targets"->"Target"->"Sources/Assets"
> 
> 2.
> 
> If I'm working on "My Application", I don't want the workspace to distract 
> me with all of the targets associated with "My Other Application" as well as 
> every other little program I write using the IDE.
> 
> 3.
> 
> The "My Application" and "My Other Application" might be very different. For 
> instance (all hypothetical), one might be a GameBoy Advance game I'm writing 
> in plain old C, and the other an opensource Win32 email client written in 
> Java and Lua on which I merely contribute, and maybe a third 
> program/set-of-programs that's some big enterprisey thing for work using 
> every damn language imaginable.
> 
> 3A: While some settings should be associated with me as a user (ex: the 
> highlighting settings for a given language, or text-editing keyboard 
> shortcuts)...
> 
> 3B: ...other settings should be specific to either "My Application" or "My 
> Other Application" (ex: auto-formatting settings, certain panels 
> opened/closed, certain panels resized differently).
> 
> Eclipse's "Perspectives" sound like a potential semi-solution to this, but 
> from my limited understanding of them, it sounds like they're not 
> project-specific, and don't cover all the types of settings I'm talking 
> about here.
> ------------
> 
> If Eclipse's Workspace is treated as a system-wide "user" concept, then you 
> have a mere two-level hierarchy of "Project"->"Sources". So you're lacking 
> the "Group of targets"/"Solution" level that ties together "My Application" 
> with its associated utils/libs/etc, while assigning appropriate "Group 
> Settings" to that entire group and nothing more than that group. This breaks 
> requirements #1 and #3B.
> 
> You could try to counteract this by treating "Workspace" as an ad-hoc "Group 
> of targets"/"Solution" concept, but then not only do you get the awkwardness 
> I mentioned in my previous post, but requirements #2 and #3A are broken.
> 
> This could all be solved with, for example, a concept of "nested classes", 
> or "a project consists of targets which have sources". But, I'm not aware of 
> anything like this in Eclipse.
> 
> 

I think you may be looking for the concept of Working Sets.  Basically, 
it lets you pick the projects that are currently visible at the time. 
Here's one dev's explanation (found via Google): 
http://wbeaton.blogspot.com/2005/11/leanin-on-working-sets.html

I always customize my perspective to add the Window Working Set item to 
my toolbar (right-click on the toolbar and choose Customize 
Perspective..., then select it under the Commands tab).  This lets me 
pick my active working set(s) by just checking items in a dropdown menu.