Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "E4/Meeting Minutes/Status 20100506"

(Compatibility Layer)
 
(3 intermediate revisions by the same user not shown)
Line 27: Line 27:
 
* Can a part also be a part container
 
* Can a part also be a part container
 
** Currently parts are model leaves and they don't have children
 
** Currently parts are model leaves and they don't have children
* Composite parts not a priority for 4.0 but we need to have a story for this in the pure e4 world
+
** Composite parts not a priority for 4.0 but we need to have a story for this in the pure e4 world
 
* Extending the model with their own custom model elements
 
* Extending the model with their own custom model elements
 
** People should be able to do this but we're not sure how this is done (Olivier Moises did it?)
 
** People should be able to do this but we're not sure how this is done (Olivier Moises did it?)
Line 36: Line 36:
 
* Susan will post a list of priority work items for getting the new look done
 
* Susan will post a list of priority work items for getting the new look done
 
** Refine detail on inactive stack on mouse over
 
** Refine detail on inactive stack on mouse over
** Not all aspects of the design will be realized in 4.0 release
+
** Not all aspects of the design will be realized in 4.0 release, but we have backup plans
 
* Searchbox still needs to be fleshed out
 
* Searchbox still needs to be fleshed out
 
** Potential 3.7 contribution in search we should reconcile with
 
** Potential 3.7 contribution in search we should reconcile with
Line 43: Line 43:
 
== Compatibility Layer Discussion ==
 
== Compatibility Layer Discussion ==
  
* Confusion about compatibility layer, people think it is distinct from the platform
+
* Confusion about compatibility layer, people think it is distinct from the platform and will be phased out
** Consider renaming it (e.g., 4.0 workbench implementation)
+
** Should instead refer to it as something like the "4.0 workbench implementation"
 
** It is really just a new implementation of the org.eclipse.ui.workbench API using technology from e4
 
** It is really just a new implementation of the org.eclipse.ui.workbench API using technology from e4
 
* Not clear to people what concepts are deprecated and what isn't
 
* Not clear to people what concepts are deprecated and what isn't
 
* What technologies will remain with us for the long term, and which will be phased out?
 
* What technologies will remain with us for the long term, and which will be phased out?
 +
* Is there a long term distinction between the "pure e4" and "platform" worlds?
 
* Make it clear the extension registry is not a deprecated concept
 
* Make it clear the extension registry is not a deprecated concept
 
** Some of the org.eclipse.ui extension points are replaced with new model-based mechanisms but vast majority of extension/extension point world isn't going away
 
** Some of the org.eclipse.ui extension points are replaced with new model-based mechanisms but vast majority of extension/extension point world isn't going away
 
* We don't have a near term goal of making a "pure e4" replacement for the entire workbench
 
* We don't have a near term goal of making a "pure e4" replacement for the entire workbench
 
** For near future, "pure e4" will be constrained to simple RCP applications, and people wanting the entire stack of RCP capabilities need to consume the 4.0 version of the platform and RCP features
 
** For near future, "pure e4" will be constrained to simple RCP applications, and people wanting the entire stack of RCP capabilities need to consume the 4.0 version of the platform and RCP features

Latest revision as of 13:39, 6 May 2010

Attendees

  • Brian de Alwis
  • Dan Rubel
  • Eric Moffatt
  • John Arthorne
  • McQ
  • Paul Webster
  • Remy Suen
  • Susan McCourt

Status

  • Working on 4.0 builds, being able to install e4 tools into it
  • Working on change to how we make the editor area, to support editors shared across perspectives
  • Still need to make stacks go away when they contain no more views
  • Need to change the model file for the e4 photo demo to catch up to recent model changes
  • Working on fixing pet peeves in self-hosting list
  • Working on e4 context menu story
    • Challenge is how to do object contributions, control visibility and enablement
  • Decorators are similar in that they are based on user's domain model rather than UI model
  • Boris has ideas about how to handle complex enablement/visibility expressions
  • Dan trying out different plugins on 4.0 builds to see what works
    • Logging bugs for things that don't work
    • Most things that don't work are plugins that used workbench internals
    • Nested editors is an interesting problem
  • Can a part also be a part container
    • Currently parts are model leaves and they don't have children
    • Composite parts not a priority for 4.0 but we need to have a story for this in the pure e4 world
  • Extending the model with their own custom model elements
    • People should be able to do this but we're not sure how this is done (Olivier Moises did it?)
  • Susan focusing on what's missing from 4.0 platform to get it up to speed with design mockups
    • Perspective switcher
    • Layout tweaking
    • McQ wants to be able to grab shadows
  • Susan will post a list of priority work items for getting the new look done
    • Refine detail on inactive stack on mouse over
    • Not all aspects of the design will be realized in 4.0 release, but we have backup plans
  • Searchbox still needs to be fleshed out
    • Potential 3.7 contribution in search we should reconcile with
    • For details see bug 304440

Compatibility Layer Discussion

  • Confusion about compatibility layer, people think it is distinct from the platform and will be phased out
    • Should instead refer to it as something like the "4.0 workbench implementation"
    • It is really just a new implementation of the org.eclipse.ui.workbench API using technology from e4
  • Not clear to people what concepts are deprecated and what isn't
  • What technologies will remain with us for the long term, and which will be phased out?
  • Is there a long term distinction between the "pure e4" and "platform" worlds?
  • Make it clear the extension registry is not a deprecated concept
    • Some of the org.eclipse.ui extension points are replaced with new model-based mechanisms but vast majority of extension/extension point world isn't going away
  • We don't have a near term goal of making a "pure e4" replacement for the entire workbench
    • For near future, "pure e4" will be constrained to simple RCP applications, and people wanting the entire stack of RCP capabilities need to consume the 4.0 version of the platform and RCP features

Back to the top