Over a million developers have joined DZone.

Share Eclipse Perspective Layouts Across Multiple Workspaces

DZone's Guide to

Share Eclipse Perspective Layouts Across Multiple Workspaces

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

Once you’ve configured Eclipse preferences to your heart’s content, you’ll often want to share those preferences across multiple workspaces. Now normally you can go to File > Export > General > Preferences to save your preferences to a properties file which you can then import into the other workspace. This will share settings such as your customised keyboard shortcuts, formatting, repository settings, etc.

But, for some reason, Eclipse doesn’t save perspective/window layouts, such as which views are open and where they are placed in the perspective. So you’ll find yourself spending another half hour configuring the window to the way you like it. After the 3rd workspace you need to create, this becomes frustrating and just wastes time.

Fortunately there are ways to save and restore these settings automatically. The first is to save the perspective into the preferences and the other is to use Eclipse’s Copy Settings feature when opening the other workspace. I prefer the first option, but I’ll mention the second option and when to use the one over the other.

Method 1: Save the layout as a new perspective

The first method is to save the perspective layout as another perspective, then export the preferences file as normal. The saved perspective’s settings will be included in the preferences file. When you’ve updated the layout,  just resave and overwrite the perspective and export the preferences again.

To save your perspective, select Window > Save Perspective As… from the application menu. A dialog should popup (shown below), prompting you for a perspective name. Enter a name  that you’ll remember, eg. My Java or Debug Jack. Click Ok once you’ve entered a new name.

Note: You can choose to overwrite one of the default perspectives, eg. Java, without fear. However, I prefer to leave these intact, so always choose a new name, but you can choose whatever works for you.

Now you can go through the normal routine of exporting the preferences to a properties file via File > Export > General > Preferences. Then import the same  file in another workspace via File > Import > General > Preferences. All you now have to do is switch over to the perspective you saved and all your layout settings will be restored. If you overwrote one of the default perspectives, you may have to select Window > Reset Perspective… to restore the saved settings.

If you’ve chosen to create a new perspective, be sure to point your Run/Debug settings to the new perspective under Window > Preferences > Run/Debug > Perspectives. For example, if you made a new perspective based on the Debug perspective, then you’ll need to change references to the Debug perspective to the My Debug for launchers you use. Luckily this is only required once as these settings are also saved when you export preferences (at least since Eclipse 3.5).

Gotcha: I use fast views a lot, and for some reason the Fast View dock’s position isn’t restored automatically. But manually restoring this is as easy as moving the dock, so it’s not that bad. Toolbar settings aren’t saved either, but I haven’t tampered with these a lot anyway since I prefer using the keyboard and mouse gestures.

Method 2: Use Copy Settings

The other method of saving your window layout is to use the Copy Settings feature when switching to another workspace.

To use this feature, first open the workspace that contains your customised layout. Then select File > Switch Workspace > Other… which will open a dialog prompting you for an existing/new workspace. Select the workspace, then click the Copy Settings collapsible section. Select the Workbench Layout checkbox and click Ok. Your workspace will open and should reflect the customised layout of the previous workspace.

Here’s what the dialog looks like:

Which method should I use?

Well, as I said before, I prefer the first method for a number of reasons. If some of these apply to you then you might want to use the first method as well. Use this method if:

  • You want to share layout settings across workspaces on different machines, eg. work and home. This method is a lot more portable because you only need one single properties file.
  • You spend 90% of your time in 1 or 2 perspectives (eg. Java & Debug) then this method works well because you only have to manage those perspectives.
  • You make a lot temporary changes to perspectives that you don’t necessarily want shared. For example, if you’ve opened a number of views that you rarely use, you don’t want to clutter your new workspace with these views. I find that I have my “base” perspective layout, around which things will change depending on the context and I don’t want these to clutter my “base” layout.
  • You want to share preferences with a colleague/friend.

Use the Copy Settings method if:

  • You want to quickly create another workspace with the saved layout without having to export any preferences.
  • You have made a number of changes across many perspectives and you want to restore those settings.
  • You’re feeling lazy. With this method, Eclipse manages a lot more things, so it’s a bit easier to manage (in the short-term), but for the longer term, the first method is best.
From http://eclipseone.wordpress.com

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}