E4/Meeting Minutes/Status 20081113

E4 Status Call

Attendees

Kai:

Jochen:

Making 3.x workbench more flexible, interesting for both 3x and e4
RAP users have different requirements for styling the UI
Have been talking about CSS
How to style the toolbar, menu bars, the header
Relationship to presentation API?
You can have one presentation for editors and one for views
Made more flexible, can have one per stack part
Can have Outlook l&f
Using preferences for customizing view action
Information density
Make it easier to have headers, move the menu bar around (not for all OS’s), move status bars
Prototyping stages
Real world use cases
E.g. Riena introduced a new workbench
Kevin to send Jochen contact for usability study

Tom Schindl

Declarative UI – looking forward to f2f discussion at ESE
Ed: is the model something you gen the artifacts and there’s no model left, or is the model there at runtime driving the application.

John A:

Some discussion on e4 resources on making things more async, spun off general discussion on async APIs
Current state is ideas in search of code
The main area where there is code today is in support of resource filters
Being able to filter out folder children
The UI presented was extremely complex so next is to figure out how to simplify the UI (don’t want to expose regex to users)
Provisioning of the repo for builds
Focus is on incremental changes to 3.x
Raises question on approach of trying to keep compatibility from the start or not
Boris: maybe its best to keep the work separate in the IDE plugin so we can explore without busting each other
Maybe we can split plugins into pieces which can have optional versions

Kevin:

CSS – need to resubmit to meet IP legal requirements then hopefully approval will follow shortly. Hope to have this by end of week.
Good discussion on declarative UI. We keep using the term “model” but we need more precision over what it’s a model of.
It’s a model of SWT: this has merit but should be a 1:1 correspondence with SWT
Higher level: could be requirements driven, or some other abstraction of the widget layer.
The latter is more contentious since there are many possibilities but it’s a rich area of investigation.

Paul:

Initial success on building against e4 repo
Goal is to be able to update e4 directly into 3.x
Discussion over what we should do with plugin version numbers.
If you’re doing e4 in a 3.x plugin., and its compatible, bump the minor version by 100.
Resources are 85% there, can apply resource feature patches
Then there’ll be the work of integrating it in the common build infrastructure
Is P2 planning on publishing and maintaining the installer?
John: not a lot of interest or effort to use and maintain
Right now we’re focused on CVS but there’s discussion on whether in the future we should consider something like git
To be created: a build page with best practices, instructions

Boris:

Created CVS directories, moved a few UI plugins over
Photo demo almost working, no menu or toolbar
Renamed plugins to be more consistent, org.eclipse.e4.ui.*
Next week is ESE with e4 symposium, currently 54 people registered
Jochen: Can we try to conference you in? Will try to arrange. Session is afternoon.
Investigation on how web components can be integrated into Eclipse.
If you already have a web component and want to show it in Eclipse how do we integrate it?
E.g. if editor can be saved, want dirty indicator to light up and behave
Current example is an IBM product. If anybody has pieces of web UI that are EPL (preferably) or other use cases then that’d be great so could show more of what we’re working on.

Additional:

Jochen: those in ESE symposium should arrange some structure around the session.
Propose people get together the hour after the members meeting. Would be 12 EST to conference Boris in.
Martin: there is a lot of information missing on the project home page. Boris believes we all have commit rights to it.
Bugzilla: top level category is Eclipse, product is e4, component is resource or UI. We need more (e.g. doc, SWT).
JohnA: there’s a project proposal called FireFly, its about mobile RIA, might be of interest to e4, we should take a look at it to see how it might interact. Having mobile use cases drives scaling down and other structural benefits.
Reminder that EclipseCon09 deadline is approach.