Skip to content
Print

The Problem of Perspective Multiplicity

2
Jun
2008

Some six years ago, I switched my primary IDE from NetBeans to Eclipse JDT (then 2.0).  At the time, I did this primarily because NetBeans was too much of a resource hog for my pathetic development machine, but I quickly learned to appreciate the power of the Eclipse development environment.  NetBeans has since made great strides of course, but at the time, Eclipse was lightyears beyond it in both features and polish.

One of the more interesting features offered by Eclipse was the concept of a “perspective”, a collection of views in a specific layout conducive to performing a specific series of tasks.  The major upshot of this was instead of the debugger views popping in and out, they simply remained hidden in a separate perspective, ready to restore to your customized configuration as necessary.  This innovation was also present in other areas, such as the CVS Team view and the Update Manager (yes, the Eclipse update system was once a set of views and editors).

You could switch between these perspectives manually of course, but most of the time Eclipse was able to just detect which perspective you needed and make the switch automatically.  If you were to launch an application in debug mode for example, the “Debug” perspective would be opened automatically, bringing useful views to the fore.  Once you were done debugging, it was easy to switch back to the “Java” perspective for more streamlined editing.  It was a good system, and it worked well.

Unfortunately, times have changed.  Don’t get me wrong, I still love having all my debug views and layout saved for me in a discrete section of the app, ready to access on a moment’s notice.  But Eclipse is no longer the single-purpose application it once was.  Yes, I know that it has always been billed as “an open tool platform for everything and nothing in particular”, but back in the day (and especially before OSGi) most people had yet to realize this.  The only language supported by Eclipse on any serious level was Java, thus the perspective system worked extremely well for organizing IDE views.  Now, Eclipse serves as the foundation for IDE frameworks supporting dozens of different languages, requiring an equal (if not greater) number of perspectives.

 image

Even in this screenshot, I’m still hiding easily 70% of the perspectives available to Eclipse.  With all of these different view collections and configurations, it’s no wonder that people often find Eclipse to be confusing compared to other IDEs.  In NetBeans (for example) you can work with as many languages as you want within a single perspective/layout/configuration.  The outline shows the relevant information for whatever file you have open, and the project explorer view is fully integrated with each language, showing all available projects and their associated structure.  Most importantly, this view is able to show project logical structure as dictated by the support module for that language (e.g. src/, test/, etc).

Effectively, other IDEs have evolved a single “Development” perspective, one which shows a generic set of views common to all languages.  Unlike Eclipse, which requires switching to the Ruby perspective or the C/C++ perspective to get the appropriate project viewer, NetBeans has one project viewer which is extensible by any module.  Eclipse has some of this with the Package Explorer, but some plugins like DLTK don’t properly integrate and so the view isn’t as streamlined.  Additionally, some functions like “Open Type” don’t work appropriately unless in the corresponding perspective for a given language.

Yes, I am aware that I could simply open any views I want within a single perspective, but that’s not what I’m looking for.  I don’t want to open five different views for navigating project files, I want to have one master view which shows me everything through the filter of whatever language is relevant to the project.  Project Explorer comes close, but it fails to handle the tighter integration (such as the “Referenced Libraries” in JDT or script outlines for DLTK).

Theoretically, Eclipse only needs four or five perspectives for the average developer working with any number of languages: Develop, Debug, Test, Repositories, Synchronize.  Obviously, more perspectives would be needed for functionality which does not conform to normal development conventions (such as “Planning” or even “Email”), but I think that these core perspectives could provide a consistent, generic framework to which any language IDE could conform.  We can already see something similar happening with the Debug perspective, which is used by Java, Ruby, Scala and C/C++ alike.

What is needed is a common super-framework to be extended by actual language implementations such as JDT, CDT and the like (similar to what DLTK provides but more encompassing).  This framework should provide a common platform with features such as project viewing, outline, documentation, type hierarchy, call hierarchy, open type, etc.  This platform would then be specialized by the relevant IDE and the same views would allow extension to fit the needs of the language in question.  This already happens with the Outline view, but it needs to occur with other common functions as enumerated.  Views which are not common to different languages (such as Ant Build or Make Targets) would of course not be contained within this super-framework, but would be separate views as they are now.  This framework would allow a developer to use a single set of views for any language, never requiring a workflow-disrupting change of perspective.

The building blocks are all in place, and such an effort would still be in line with the Eclipse philosophy of total extensibility, it’s merely a question of implementation and opinion.  The implementation is simple, as I said, most of the functionality is already available (often redundantly) in any one of the many IDE packages.  The bigger challenge is to convince those who have the power to make the decision.  Eclipse 4.0 is coming, it should be an interesting road to follow.

Comments

  1. An interesting point, but (a) each has their own icon, and (b) you can turn the text names off to shrink space (which is just as relevant if you have five open perspectives as if you have ten). Why they aren’t just icon’d by default with mouse-overs for those that can’t remember, I don’t know … and the option to turn it off (right-click on the perspectives bar and select ‘Icon only’) isn’t exactly obvious.

    The other thing is that there’s relatively few systems which require many languages simultaneously; though I think that we’re getting to a stage where having two languages are more common than just the one.

    The common navigator certainly helped, but we need a common repository perspective as well and a common debug one too. That would help other languages fit in.

    Alex Blewitt Monday, June 2, 2008 at 3:00 am
  2. Daniel, the increasing number of perspectives is indeed a problem. While many you can easily live without (e.g. I never use the CVS ones and I wrote them!), as you noted you also can’t just live in one. In truth, at the start we had this notion of each work area getting its own perspective but at the time only were dealing with a limited number of work areas. Who knew how big Eclipse would grow!

    We do now have the common navigator which in theory would allow you to have a single navigator that you can use for any project type. However, as you know many commands only appear under certain perspectives and different approach to that is needed. At the core is the problem of knowing what the user is trying to do and providing tools specific to that task. Aside from the problem of cluttering menus, keybindings are a place where this problem is really apparent. Basically, there’s only so much of everything to go around – menu space, toolbar space, keys to be bound – and we need some way of switching between alternate groupings.

    There has over the years been discussion around formalized workflows (of which perspectives were a weak mechanism to address this, but so too capabilities) but a comprehensive executable model of UI workflow has so far eluded us. But I believe your ideas around Develop vs. Test vs. Debug are on the right path.

    I’m glad your thinking of ways we can solve all this but I don’t agree with your characterization of the implementation being simple. Either you see a simple solution which so far we’ve overlooked, or you’re being, well, a little naive. For example, so far JDT hasn’t moved to the Common Navigator because we just haven’t been able to make it as performant. Which though isn’t surprising, because strong specific solutions always outperform weak general solutions. Also you need to look at our resource model and project structures when discussing a logical layout. This incidentally was a breakout group topic at the e4 Summit (http://wiki.eclipse.org/E4/Resources).

    This is a subtle, complex problem with potential massive downstream side effects (ie. work required for existing plugins to adopt). Its not just a matter of “convincing those who have the power to make the decision”, which kind of implies we have a solution but either can’t decide or can’t be bothered.

    In any case I like the fact that you’re thinking about this problem from a kind of holistic/task point of view. Its also great to hear from people who are also familiar with other IDEs such as NetBeans as we can always learn from others.

    Kevin McGuire Monday, June 2, 2008 at 8:24 am
  3. It’s probably just me being a little naive. :-) I agree that keybindings and toolbar space are problems worthy of consideration. For common functions like open type, there’s obviously no conflict (just use Ctrl+Shift+T and choose the correct mode using the current project), but advanced IDEs like JDT represent a veritable explosion of functionality. What may be the right path here is to take inspiration from TextMate, which actually has mode-specific keybindings. Effectively, the keybindings change to be relevant to whatever file you’re editing. This concept could be extended to projects (CDT keybindings if editing a C project, JDT if Java, etc). I’ll grant that this could certainly be confusing to people, and consistency might be an issue. The keybinding framework would have to allow for not only global and mode-specific, but also bindings which are shared between certain modes and perform similar functions. (e.g. if I change my keybinding for “Rename…”, I want it to change in JDT, CDT, RDT and SDT simultaneously).

    The common navigator problem seems a bit odd to me. I guess I don’t understand why this is a performance issue, especially with things like VIRTUAL trees to lazy-load where necessary. I think this problem of the common navigator is probably the biggest issue with perspectives now. If I could just have full-featured navigation in all project types in one view, I would be able to tolerate the annoyance of using different Open Type functions etc…

    Daniel Spiewak Monday, June 2, 2008 at 9:43 am
  4. I agree and I hope E4 will become a more _Integrated_ Development Environment for multiple languages. At moment, it is more like different IDE packed together side by side – but not integrated! Not in all areas, but commands, keybindings, colors (annotitions), fonts (compare editors), navigators are only some examples.

    Teddy Walker Monday, June 2, 2008 at 1:35 pm
  5. I use only one customized perspective. That’s it. I don’t ever like it switching perspectives on me, so I always tell it “no” and to remember my decision. Works well that way.

    I just wish I could tell Eclipse to stop moving the back button around in the middle of clicking back through files.

    Tom Tuesday, June 3, 2008 at 3:34 pm
  6. Oh, and the syntax highlighting colors different by file type is weak, too. Eclipse is great for Java, but I’m still not convinced that it’s good for anything else. At least the editor sort-of works the same for different file types.

    Tom Tuesday, June 3, 2008 at 3:37 pm
  7. Actually, I never use the back button. Alt+Left is the key binding, much faster than mousing all the way up to the toolbar.

    With regards to Eclipse’s syntax highlighting, this is the solution I use: http://www.codecommit.com/blog/eclipse/general-purpose-editor-within-eclipse It’s not perfect, but it gets the job done.

    Daniel Spiewak Tuesday, June 3, 2008 at 3:38 pm
  8. Back button vs. Alt+Left depends on my mode at the moment. But I usually get retrained pretty fast to avoid the toolbar.

    Tom Thursday, June 5, 2008 at 9:54 am
  9. And thanks for the editor recommendation.

    Tom Thursday, June 5, 2008 at 9:55 am
  10. The other problem with the perspective issue is that the sort-of-but-don’t-quite act as separate environments. What I mean by this is that right now I’m messing with some PHP code (having the php tools installed); however the developers of the project decided to name most of their php files with a .class; since Eclipse thinks that .class is associated with Java, I’m unable to convince the editor to display syntax highlighting which is a major pain. For light weight editing I often just use Notepad++ and can ’switch’ on the fly to a different syntax. I know that Eclipse uses a completely different way to implement syntax highlighting (which for fully supported languages is much more powerful), but the end result is that perspectives are more like “workbence layout configurations” than anything else… Making the type assignments be both global and project-nature based seems to me the best way to solve this, but maybe someone else has a brilliant idea on a better way to improve things.

    The other issue I ran into was mucking around with an Eclipse RCP/plugin set that I worked on. We had 2 perspectives, and one file type, all we wanted to do was to be able to assign a different editor to the file type depending on which view the user was in, but there is no ‘good’ way to do this (this could also be made easier by changes to, or adapters for, the common navigator).

    Robert Thursday, June 5, 2008 at 12:24 pm

Post a Comment

Comments are automatically formatted. Markup are either stripped or will cause large blocks of text to be eaten, depending on the phase of the moon. Code snippets should be wrapped in <pre>...</pre> tags. Indentation within pre tags will be preserved, and most instances of "<" and ">" will work without a problem.

Please note that first-time commenters are moderated, so don't panic if your comment doesn't appear immediately.

*
*