Re: [e4-dev] Plans for 4.1

[yves.yang@xxxxxxxxxxx]

As for declarative UI, I have the following plan:
  1. Support of event handling in C/S
     We (me and Angelo) have started on this tropic with the integration
of Spring: Bug 320405 - CLR Class managed with Spring to use Spring
DI and Spring DM
  2. Declarative Graphic 2D
  3. Declarative Animations
  4. Support of JavaScript
  5. Web UI
     4.1 RAP integration
       Bug 298589 - make XWT runnable on rap
     4.2 SWT/BE integration

Best regards
Yves YANG
> Hi,
>
> Now that we finally shipped 4.0 here's my work plan and wishes for the
> next 4.1:
>
> CORE:
> =====
>
> * Make the core-ui widget-toolkit free:
> ---------------------------------------
> We accidently introduced a dependency on SWT in
> org.eclipse.e4.ui.workbench which violates one of the core designs for
> e4. When we think into the future e.g. having a WebUI, ... not violating
> this core design is very important.
>
> The bug in question is 319713.
>
> * Easier dealing with selections:
> ---------------------------------
> The current concept works fine for getting access to the current
> selection but fails IMHO when pushing a selection into the system.
>
> The bug in question is 321201.
>
> * Dealing with Single vs Array-Values:
> --------------------------------------
> Somehow related to selections I'd like us to find a solution to the
> problem when one is pushing a multi-value into the context but expects a
> single value to get injected. At least we need to find a replacement for
> the ISelection/IStructuredSelection from 3.x.
>
> The bug in question is 316392.
>
> * Rethink the lifecycle annotations:
> ------------------------------------
> I think we need to rethink this because 90% of its current features are
> covered by the model-processors and addons.
>
>
> MODEL:
> ======
>
> * Binding* is using String-references, ....:
> --------------------------------------------
> The current Binding* elements need some improvement to not use string
> references, ... .
>
> The bug is 320171.
>
> * ModelFragments and Bundle-lifecycle:
> --------------------------------------
> Our current model fragments contribution does not support the dynamic
> nature of OSGi.
>
> The bug is 302821.
>
> * Making Wizards/Dialogs part of our Model:
> -------------------------------------------
> I thought I already filed a bug for this but it think we should extend
> our model to also cover Wizards/Dialogs. I think making them part of our
> model makes reusage of our Parts there easy and keybinding-scoping easier.
>
>
> RENDERING:
> ==========
>
> * Better support for EMF-Modifications:
> ---------------------------------------
> We currently don't support all EMF-Actions like move:
> - inside a container
> - from containter to container
>
>
> * A convenience API for users:
> ------------------------------
> We need to find an easier way for people to write their own renderes.
> The code is fairly complex. We should think about an Widget-Abstraction
> the internals rely on so that people don't have to write the listeners
> code, ... .
>
> * Rethink the usage of Sashes for Window-Splitting:
> ---------------------------------------------------
> We currently use the SWT-Sash to split up windows. I think this is
> suboptimal because e.g. I'd like to use the lower-right-corner of the
> editor resize it horizontally and vertically. Beside that I think it
> makes the implementation of FastViews harder. I've started experimenting
> with a SashForm replacement which is available from 317849.
>
> * CSS:
> ------
> My main problem with CSS today is that there's no real description of
> the attributes, ... one can apply on elements. If I'd have the choice
> I'd like to have an EMF-model backing up the whole thing (see tooling
> what this could provide us).
>
> I also think we are dragging in things like batik for features we don't
> really need but I'm not as deep into this topic. We don't support the
> full CSS-Features anyways so we should concentrate on the most important
> ones:
> * Styling by ID
> * Styling by Class
> * Styling by Element
> * Support for :ACTIVE, ...
>
> All other things coming with CSS are IMHO less important.
>
>
> TOOLING:
> ========
>
> * Work on the Forward Compat Layer:
> -----------------------------------
> I'd like to invest more dedicated time into my forward compat layer
> (currently it's been only driven by my model-editor) but I could need
> some help from other team members
>
> * ModelTooling improvements:
> ----------------------------
> There's a vast number of things to improve:
> - Better support Copy&Paste - Bug 321019
> - Integration of Documentation and Help
> - ...
>
> * DI/Service-Tooling:
> ---------------------
> I think it would be extremely important to add some tooling for DI and
> help people looking up our "20 things". The current modeltooling already
> introduced Wizards for Part, Addon and Handler-Creation.
>
> * CSS:
> ------
> Add tooling to edit CSS and probably even modify live like e.g. the
> LiveModelEditor provides this for the application model. There's a
> proposal of Sven Efftinge and Sebastian Zarnekow for ESE. As outlined
> above I'd like us to use EMF to store the CSS-Model at runtime which
> would give us easy access to Xtext and the possibility to edit/modify it
> at runtime and design time.
>
>
> As you see this list is very long but to make the Eclipse 4.1
> Application Platform a valueable release and get it into the market as a
> viable UI-Application-Platform we'll need fairly all of this things
> implemented. I don't know if I manage to contribute all this because I'm
> still doing this too the most extend in my spare time.
>
> Tom
>
> --
> B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl                                        geschaeftsfuehrer/CEO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 5/1    A-6020 innsbruck      phone    ++43 512 935834
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>