| What if there was no such thing as a workspace? Instead, the project/package explorer just reflected what was on the filesystem, and provided a way of filtering what is displayed? Metadata is stored in the user’s home directory. Projects are just directories containing .project files which Eclipse could automatically discover (and cache) when first started. Non-project directories would be accessible without requiring any action by the user, so Eclipse could finally be used as a replacement for Emacs. Filtering could be context specific, so changing perspective could switch filters, for example.
Benefits:
- No more importing, just adding a .project file just provides more functionality. - Repo working directories could be automatically discovered. - Project/package presentation is not limited by workspace hierarchy, novel presentations could be explored. - Global preference problem is solved. - No refreshing, ever.
So what about different plugins/target definitions? Simple. Start multiple instances of Eclipse, each of which can have it’s own metadata location. I already do this (and I bet others do too) because switching workspaces is so painful; at any time I might have three or four instances of Eclipse running. Doesn’t this create a preference problem again? In my perfect world, Eclipse checks my home directory for existing metadata and asks me if I’d like to import the preferences into the new instance.
Ok, so I know I’m dreaming. But removing a whole layer of complexity that developers have to contend with would make Eclipse much more appealing IMHO.
Greg
I disagree that multiple workspaces are a worse practice, in fact I'll argue otherwise.
Multiple workspaces makes things a lot simpler when you are working with multiple unrelated projects (I dont mean Eclipse IProjects, just work projects). For example I have four Eclipse workspaces: one for RustDT+Goclipse+DDT+MelnormeEclipse development, another one for Eclipse Platform contributions, another one for CDT contributions, and finally another one for working with Rust and Go projects.
If I put all of these together (even assuming there were no Target Platform restrictions) it would massively clutter up my Eclipse workspace. And then I'd have to use Working Sets to isolate those each conceptual group of projects, but why bother? There is nearly no benefit, AFAIK, to Working Sets, and yet there are *a lot* of cons. It's more work and a lot of eclipse components don't work with Working Sets at all. For example the "Build All Projects" command does not work with Working Sets (this has implications for projects that don't use incremental builders). The "Refresh All" command (a command I use a lot due to use some external Git scripts on some projects) doesn't work with WS either. The Git Repositories view doesn't work with Working Sets. Working Sets don't allow you to customize the perspective per working set. So if I want to customize it, I have to create a different perspective, and when I switch working sets, I also have to switch perspetives manually.
Multiple workspaces allows you to have different Eclipse plugins per workspace. Working Sets does not. This is useful for me when the work projects I work on a given session use completely different plugins than others.
Working Sets are more work for the user to manage. Whenever you add a new project, you have to add it to the corresponding working set. Not all wizards support this. (RustDT/Goclipse/DDT don't, for example). But even with the wizards that do support it, it's still more work than simply using multiple workspaces - you still have to select in the wizard which Working Set to add it to. With multiple workspaces there is no such need, it just adds it to the current workspace.
And in the face of all this, the only downside of multiple workspaces is you have to copy/manage prefs, but that is a one-time cost when setting up a new workspaces (or when you change a preference). The cons of Working Sets on the other hand hit you nearly every time you use them.
And I don't even see any other advantage of Working Sets, other than you can combine and activate multiple working sets at once, you are not restricted to just one. But I was never in a situation where that was useful.
|
