Home > Articles > Programming > Java

📄 Contents

  1. FAQ 319: What is eScript?
  2. FAQ 320: Language integration phase 1: How do I compile and build programs?
  3. FAQ 321: How do I load source files edited outside Eclipse?
  4. FAQ 322: How do I run an external builder on my source files?
  5. FAQ 323: How do I implement a compiler that runs inside Eclipse?
  6. FAQ 324: How do I react to changes in source files?
  7. FAQ 325: How do I implement an Eclipse builder?
  8. FAQ 326: Where are project build specifications stored?
  9. FAQ 327: How do I add a builder to a given project?
  10. FAQ 328: How do I implement an incremental project builder?
  11. FAQ 329: How do I handle setup problems for a given builder?
  12. FAQ 330: How do I make my compiler incremental?
  13. FAQ 331: Language integration phase 2: How do I implement a DOM?
  14. FAQ 332: How do I implement a DOM for my language?
  15. FAQ 333: How can I ensure that my model is scalable?
  16. FAQ 334: Language integration phase 3: How do I edit programs?
  17. FAQ 335: How do I write an editor for my own language?
  18. FAQ 336: How do I add Content Assist to my language editor?
  19. FAQ 337: How do I add hover support to my text editor?
  20. FAQ 338: How do I create problem markers for my compiler?
  21. FAQ 339: How do I implement Quick Fixes for my own language?
  22. FAQ 340: How do I support refactoring for my own language?
  23. FAQ 341: How do I create an Outline view for my own language editor?
  24. FAQ 342: Language integration phase 4: What are the finishing touches?
  25. FAQ 343: What wizards do I define for my own language?
  26. FAQ 344: When does my language need its own nature?
  27. FAQ 345: When does my language need its own perspective?
  28. FAQ 346: How do I add documentation and help for my own language?
  29. FAQ 347: How do I support source-level debugging for my own language?
  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

FAQ 345: When does my language need its own perspective?

Your language needs its own perspective only when you have a certain collection of views and editors that work together and would be cumbersome to open individually. Adding a new perspective should be done with reservation, though. If you add a new perspective and bring users there to do programming in your language, you have made many hidden assumptions about how programs are developed and in what sequence. Ask yourself, What if people want to develop programs written in my language and at the same time in Java and/or C? Will my perspective be a help or hindrance?

Think of perspectives as one of the windows in a virtual desktop manager. When you start using a virtual desktop, you like the separation of function. You use one of the windows for editing, one for reading mail, one for browsing, one for programming. This is great. You can switch between tasks with a clever keyboard shortcut or a simple mouse click. Inevitably though, you get sloppy, separation rules are broken, and all applications end up in one window. The virtual desktop ends up as a useful tool for demos, but that’s about it. The same issues apply to perspectives. People like them for their separation of context and their memory of what views are chosen with their layout. However, people can manage only a limited number of perspectives and are particularly annoyed when an application rudely jumps to another perspective. Be sure to ask permission from the user, as the Debug perspective does.

Perspectives are created by using the org.eclipse.ui.perspectives extension point:

            name="Cool Perspective"


FAQ 346 How do I add documentation and help for my own language?

  • + Share This
  • 🔖 Save To Your Account