Re: [e4-dev] E4-Workbench needs a new plugin

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi,

Ralf Sternberg schrieb:
> Hi Tom,
> 
> thanks for explaining. I think the split is indeed an advantage to RAP.
> 
> On the other hand, the more I think about it, I wonder whether I like
> the idea of an abstraction from SWT, which is in itself a (pretty good)
> abstraction already. For example, won't splitting JFace make things
> horribly complicated? And what is the benefit of your approach compared
> to the longed for SWT/Qt port? I'm just asking - and sorry if this has
> been discussed a hundred times before.

Let's start with the following :-)

In my opinion the usage of IStructuredSelection at the position it is
found currently is:
a) Not needed and one could also use an Adapter
b) Has some problems in the current form because it doesn't allow to
pass on multi-selection.

So it is subject to change anyway at least that's my opinion.


Now let's look at the second paragraph.

SWT is going to be the Number 1 target of our work. Splitting JFace into
an abstract and concrete part is that same idea than e.g. Databinding is
following with great success!

The tight binding between JFace and its concrete implementation (e.g.
Tree/Table/List) has been a problem already nowadays where we wanted to
open JFace-Viewers to other Structured-SWT-Controls (e.g. Nebula-Grid,
Nebula-Gallery). From an outside user nothing will change if JFace is
split into 2 modules beside the fact that then modules like
o.e.e4.ui.workbench only need to depend on the generic one.

I'm not sure when you talk about an abstraction of SWT - maybe you talk
about UFaceKit but I repeat it once more. The main target of E4-UI is
not UFaceKit but *SWT*.

UFaceKit has beside the abstraction it provides many feature you won't
get in SWT simply because it's not the task of SWT to abstract
higherlevel UI-Concepts for you, provide a reflective-API. ... . You can
see UFaceKit as a replacement for JFace but going beyond it by directly
integrating into Eclipse-Databinding, provide themeing, ... like Riena
Ridgets also do.

UFaceKit is exposing lesser/no lowlevel API like a GraphicContext,
Image, Font, Color but uses declarative approaches (e.g. CSS) which
makes it easier to port to other platforms (e.g. we are currently
looking at OpenGL, Android, GWT and already support SWT/Swing/QT).

When we talk about the keeping the o.e.e4.ui.workbench free from SWT the
important thing to notice is that this ensures that we don't create
internal dependencies on specific SWT-Widgets.

This would be a real problem because the possibility to exchange e.g.
CTabFolder through another widget PShelf, the native menu through a
ribbon like one, is the replacement of the Presentation-API from 3.x.

Exchanging the rendering technology to something different than SWT is a
nice side effect (and I admit one I'm really appreciate:-) but it won't
happen if this makes it harder to provide a clean and concise SWT
implementation.

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