| Re: [e4-dev] Workbench Customizations? |
Hi Eugene,
> Arguably, the main "killer app" of the E3 was the RCP - i.e.
> refactoring of the IDE that allowed customizing the workbench layout,
> reduced dependencies on workspace and other frameworks that are more
> specific for IDE application. I wonder - will there be any more
> enhancements in that department in E4?
Many of the things we do in e4 (lowercase! :-) will make the core frameworks easier to use for RCP-style applications, and many of the
> I wonder if anything from the list below will be easier in E4. For all
> examples consider projects built on top of WTP or CDT - i.e. IDEs that
> are built upon complex multi-plugin codebase:
> 1. There is no control over UI contributions. I.e. if some framework
> (say, GEF) contributes a view (Palette View) you can try to conceal it
> using the "Capabilities" but that really will only hide it from some
> UI parts (i.e. you will still see it when pressing Ctrl+3). Sometimes
> this results in some unwieldy UI when user sees UI that really is not
> needed for the particular task.
Yes, this will become easier with e4. The plan is to go through the application model (an EMF model) with all UI-relevant contributions. This will give you a single place where you can hide/filter/sort things as necessary for your application.
> To me the best solution would be to let product control such
> registries and/or provide builders for menus/toolbars. This will not
> only allow removing the UI contributions but will also let products:
> 1. "Override" contributions by providing other views/editors/wizards
> that are specific to particular task.
> 2. Provide better control over menus.
Yes, exactly. All UI contributions will end up in the application model, and there will be an opportunity to change that model before it is rendered.
> 2. Will it be easier to customize the workbench UI? I.e. what if we
> need to change the perspective switcher to one like in QtCreator?
> Please not - the resulting code should not break WTP/CDT.
Yes - since we have a separation between the application state (the model) and the renderer, you can write your own renderer - from scratch, or for tweaking the rendering of certain elements if you don't need a full replacement renderer. This is one of the things that Tom Schindl is interested in.
> 3. Is there any change in policy with views? In E3 all views are
> basically equal while some other IDEs (i.e. NetBeans) make some
> "views" become a part of editor.
> Consider the GEF Flyout Palette. It can be used either as standalone
> view or become a part of editor area. I believe it would be great if
> other views like Outline and Properties would follow the pattern. Many
> editors don't really need both views - i.e. JDT editor have little use
> for Proprties and some visual designer might not need the Outline - so
> current solution doesn't make effective use of the screen area.
We are trying hard to avoid the use of singletons, and built-in assumptions on the context in which a UI component is being used. Many existing UI components, however, do use singletons, and make assumptions on where they are used. So for new "pure e4" components, things similar to what you propose should be possible.
> I know that E4 has a new workbench model that should make such changes
> easier - but I wonder if there are some code examples for these
> particular tasks.