Community
Participate
Working Groups
Similar to the support views have for categories, including: (1) Defining a hierarchy of arbitary depth. (2) Assigning a perspective to any category in the hierarchy. (3) Retrieving categories from the IPerspectiveRegistry For example, I could place Java dev related perspectives in the "Java" category, or C++ in the "C++" category. This also has numerous applications in the RCP world.
Lately the workbench has caught a pretty bad case of Extremis Categoris - we're categorizing everything. I can't help but feel that perspectives are last on the list of workbench extensions that need some form of categorization. Realistically, how many perspectives appear in a large application?
I used an IDE example but this requirement is more related to an RCP app. Enterprise organizations may have a large number of applications (perspectives) possibly provided from a number of different sources. Categorization of perspectives is required to provide a nice interface to end users for traversing through the available applications. I have seen real world examples where the number of perspectives can become very large, but even with a smaller number of perspectives many organizations have UI requirements for hierarchical navigation of their "applications". In some instances it's just for aesthetic reasons, and for others it’s an attempt to minimize training costs by mimicking the UI of an older application as they rebase on Eclipse RCP. The perspectives that ship "out of the box" with Eclipse don't need to be placed in any category, in fact, it's probably better to let the end user or administrator decide what categories to place them in. This may mean that instead of adding a "categoryID" attribute to the perspective extension-point there is a separate extension-point called perspectiveCategories in which you create categories and enumerate the perspectives they contain.
Kim, I worked on a large scale Eclipse product that has 15 perspectives in the list when all capabilities are enabled.
15 doesn't seem that egregious. 15 should fit nicely in the dialog without any scrollbars.
There are currently no plans to work on this feature. PW
Changes requested on bug 193523
I would like to add my opinion here. There really is a problem regarding perspectives, but it isn't that categories are wanted just for the sake of categorization, but allow me to explain. We have an eclipse product; we have today three perspectives. We ship with JDT. Our perspectives, "ideally" are named: OurProduct Perspective1 (like SuperProduct Authoring) OurProduct Perspective2 (like SuperProduct Debugging) basically. The reason is so that they group together in the perspective chooser, otherwise the user can't easily pick out "our" perspectives. Eclipse perspectives all name themselves as if they are top-level: "Debug" "Resources" Now, we would be satisfied, but the real usability problem occurs at the perspective bar; our company name is longer than "Acme", and what happens is in just about every case our end-users see: "SuperProduct..." "SuperProduct..." and if we are lucky "SuperProduct A..." "SuperProduct D..." What we are going to resort to for now is to abbreviate the product name, so we have perspectives like SP Authoring SP Debugging but that is quite unprofessional! So, categories. If we had categories (just like views after all!) we wouldn't worry, and then I would have a product preference (for product authors to configure) that decides whether to prepend categories to perspective names or not). I would like to hear thoughts on this, as we have been producing a highly successful product for many years, and this usability concern is pretty high up there in our list. Thanks!
Oh; alternatively, a short name/long name for perspectives would do too, although that would be a new bug.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
