[
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
|
I expect you can count on lots of help. The idea of updating a platform in
which models are so plentiful without leveraging a common metamodel (i.e.
Ecore) seems incredible, to me. I hope EMF and related technologies in
Modeling are seriously considered for use in e4.
Thanks for bringing it up, Tom.
Best Regards,
Rich
On 4/3/08 9:00 AM, "Ed Merks" <merks@xxxxxxxxxx> wrote:
> 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
>
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
