[
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
|
Tom,
Of course I would be more than happy to help with experiments! Using EMF
models would be a boon because they would directly enable a rapidly growing
stack of modeling technology. Much of what needs to be built here is
incredibly complex, though it might not appear so on the surface, and we
have a diverse established community with a wealth of experience in this
domain. So while I'm sure the obvious temptation will be to say "we want
something much simpler than EMF because we really don't need all that
complexity", the end result, in the far distant future, once all the hard
problems are understood and solved, will inevitably to be something pretty
much like EMF. I've been around the block a few times and have seen the
predictable patterns that lead toward the same inevitable conclusions each
time. For example, is SDO really simpler than Ecore, or just different?
We do have a working prototype of a binary serializer:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206267
I've not had time to properly integrate it (and to commit to the long term
support that's expected from Eclipse's projects).
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Tom Schindl
<tom.schindl@best
solution.at> To
Sent by: E4 developer list
eclipse-incubator <eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e rg>
clipse.org cc
Subject
04/03/2008 03:34 Re: [eclipse-incubator-e4-dev]
AM Initial discussion on the
'modelled' workbench UI
Please respond to
E4 developer list
<eclipse-incubato
r-e4-dev@eclipse.
org>
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
