[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Plans for 4.1
|
Hi Tom,
I agree with you about CSS engine which must be improved. I think the
most important to improve the CSS engine is to "Remove
ICSSPropertyHandler and change that with IPropertyDescriptor".
I tried to explain IPropertyDescriptor into the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=298081
ICSSPropertyHandler apply styles for several kind of widget (Button,
Text...) where "instanceof "is used for that, (not very clean).
Problem with ICSSPropertyHandler is :
* it's difficult to discover the code which apply styles for a widget.
* CSS engine cannot know which property can be applyied for a widget.
The idea about IPropertyDescriptor is to manage apply styles into the
Element wrapper of teh widget (WidgetElement, ControlElement,
ButtonElement...). It give us a lot of benefit like
* resolve the 2 problems explained above.
* Reset of the apply styles can be better managed.
* easy to know properties for a widget. This information can be used
with a CSS editor.
If IPropertyDescriptor must be extensible to manage custom properties
(like ICSSPropertyHandler).
@Yves : thank's to speak about our work about XWT-Spring support. I
think next week I will send a patch with my work. I have started to
write something at http://wiki.eclipse.org/Using_Spring_with_XWT But
it's not finished (sorry with my bad english)!
Regards Angelo
2010/8/5 <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
>>
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
