[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' workbench UI
|
Hi Eric,
I'll split my replies into different mails to comment on different
sections of your mail independently ;-)
First of all we already discussed a lot on this on EclipsCon and I fully
agree with the points you are making. Having dived myself into the
Platform-Code I know how hard it is for a contributor to add a certain
feature to the current codebase (it's fustrating that if you worked on a
feature the last weekend you'll need to restart from the beginning the
next weekend because there are so many classes involved). Having a flat
structure would improve this a lot.
Eric Moffatt schrieb:
Hello, since I'm the person respnsible for the current modelled UI demo
presented at EclipseCon I thought I'd kick off the discussions about the
architecture we're going to end up with by presenting the thought
process that lead to the current demo's structure...
[ Coffee Alert: this email is somewhat long but I wanted to capture
everything in one place. You may want to get a fresh cup before
proceeding...;-). Once it's been through the mill here for a bit I'll
capture the result, polish it up with screen caps etc and put it on the
WIKI. ]
Done and ready to start.
The goal of this email is to stimulate discussion about the design and
its implementation; it's an open invitation for *YOU* to become involved !
The general idea is to provide an implementation that is much simpler
both in its internal implementation and in its external API's (while
maintaining the ability to host 'API-clean' extensions written against
3.x). As alluded to in McQ's talk at EclipseCon much of the codebase
has, over time, become 'baroque' (read 'overly complex'). UI code is
particularly susceptible to this type of erosion since any GUI is under
unrelenting pressure from its community for 'tweaks' (this can be
treated as a constant that the new architecture should at least attempt
to mitigate).
I see re-working this code as simple self-preservation, it's just as
hard for me to work with as it is for external developers; I've just
spent the requisite 2-3 years working with it and have grown calluses to
mask the pain...;-).
The bottom line is that it's become soooo complex internally that it has
become extremely difficult for us to get any significant level of
community input (our *real* goal here!). The learning curve to
understand enough to create a valid patch for any but the simplest of
fixes is simply too high, requiring too much of an investment from the
would-be contributor. It also means that when patches are submitted
(even by truly solid devs) the committers have to spend a -lot- of time
working with the contributor to refine it to cover a slew of 'side
effects' that, while not necessarily a part of the functionality of the
new feature/fix, are required in order to have it observe all of the
niceties of 'proper' integration into the Workbench (i.e. Does it handle
all the view options like Movable, Closable? Themes? Correct use of
Workbench constants / prefs?...ad nauseam, especially for the poor sod
who contributed the original patch...;-). While some of this is or can
be aided by simply documenting the requirements, hopefully when we're
done we'll then be in a state where external contributors can provide
features/fixes without adverse side-effects on other parts of the
implementation. The same issues serve to limit the effectiveness of the
current committers, slowing the overall pace of bug fixing and enhancement.
This -must- change...OK, how ?
Well, it's pretty well generally accepted that the Model/View/Controller
architecture is the way to go in UI's and, indeed, much of the current
framework is implemented this way already. Unfortunately we have way too
many different models. In many cases this is the result of each UI
enhancement being discreetly coded by the individual responsible and,
being good GUI developers, they each implemented their own MVC
architecture. We'll see some examples later...
The basic premise behind the demo is to migrate the various models under
a single modelling architecture and show how this structure can
subsequently be used to drive the UI (rather than "divide and conquer" I
call this "consolidate and conquer"...;-). The Model Engine and its
elements would become 'first class' citizens in the platform which we
can then 'tool up' as appropriate (scripting...) and get maximum benefit.
The rules are simple (and many folks will say "Duh") but you'd be amazed
at how many folks break them...
1) The modelling engine is responsible for containing the currently
defined state and reporting any changes to its listeners. Proper
implementations would also support save/restore and transactions with
(optional) undo/redo. Clients will be supplied with an implementation
(implementations?) and will gain immediate benefit from using it (they
can expect standardized JFace viewer support including automatic update
and editing support).
2) The GUI components are responsible for presenting the current state
of (some subset of) the model and maintaining the correct display of the
model's state as it changes. In this case the GUI is everything you see
when running eclipse except for externally defined parts (even here we
expect to 'port' many of our existing views over to a modelled approach).
3) In a non read-only world the GUI will also map certain user gestures
(i.e. clicking a tool, activating a view) onto -proposed- changes in the
model. The word 'proposed' is very important because it's IMO the most
common cause of breakages in the architecture. the GUI bit proposing the
changes should never take any presumptive action (like adding the
element to its list, changing the item's name...). It should say "the
user wants to do 'x' and then sit back and listen like everybody else to
see what actually happens. This allows a GUI whose model contains
internal logic (perhaps an attempt to rename an object to "Foo" will
result in a name clash so the model automatically sets it to "Foo(2)").
NOTE: we gain an immediate advantage for threading here. Changes to the
model can be made from -any- thread but the listeners are always fired
on the GUI thread, little or no need for 'sychExec'.
*[ Disclaimer #1: the current ModelElement implementation is sufficient
to get started but should likely be replaced with a 'proper' modelling
engine ASAP. Candidates? However, whatever the actual implementation(s)
are the public API should be as simple as the ModelElement's. ]*
Well I guess EMF would be the most natural choice here, not?
In my opinion there are multiple reasons:
-----------------------------------------
- it's approved and has shown its stability/scalability in many big
projects. I think we all agree that we should not reinvent the wheel,
right?
- you get fairly everything for free (change-management,
(xml-)serialization (I somewhere heard that Ed and his team work on a
binary format, is that right Ed), ...) and a lot more if I look at the
different emf subprojects (constraint checking / validation,
persistance, ... )
- you get a whole project team / community to jump on the E4 train and
help you and we all agree the more diversity E4 has the better it will
get. We / you know the guys behind EMF which should not be
underestimated when choosing a technology
- No Licensing issues because EMF is under EPL
I'd volunteer to work with you to start a short experiment and transform
what you currently have into an EMF-Model and maybe some EMF gurus can
also help us to do this experiment? Once I get the demo running on M6 +
OS-X, I don't know what's the problem because I followed the wiki step
by step (besides using M6 instead of the integration build, do I have to
switch back this one?, Does it work on OS-X?).
I need to get some work done and when I grab the next 2 cups of coffee
I'll comment on the next part of your mail.
Tom
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
