Re: What is Riena about? (was AW: AW: [riena-dev] Ridgets)

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Elias,

Volanakis, Elias wrote:
> Hi Scott,
>
> from my personal point-of-view (having done a couple of RCP projects)
> the benefit of Riena that is important to *me* is, that Riena will
> provide a more "accessible" technology for writing rich clients based on
> RCP. 
>   

I'm completely in favor of this as a goal (making Eclipse/Equinox more 
accessible for writing rich clients based upon RCP), but it does seem 
different from what Riena is saying/has said about itself.  Not better 
or worse, just different.


> Accessible in a dual sense:
>
> * for end-users Riena should be more accessible because of the "process
> oriented" UI that moves away from the ide-centric Views and Editors
> metaphor. To further increase acceptance by end-users Riena is also
> aiming to provide support for customizable look-and-feels. 
>   

So again I don't really have any problem with the articulated goal here, 
although as I understand it the ideas would seemingly overlap with a) 
e4; b) the work in Platform UI for 3.5...which begs the question of how 
are contributors and consumers supposed to see the relationship between 
Riena and these two efforts (?)

> This should reduce the amount of effort and customization required to
> create a user-friendly, nice-looking application based on RCP. Don't get
> me wrong here: I really like Eclipse RCP and it's flexibility. Hower the
> framework is quite complex because of that. A solution already sculpted
> towards a specific use case (i.e. process oriented UI) could lower the
> barrier of entry for that use case. My understanding is that this is the
> road Riena is trying to follow.
>   
> * for developers Riena should be more accessible because it is exposing
> existing Eclipse technologies -- like Databinding and JFace Viewers --
> through more "high-level" APIs (for example the Ridgets). This should
> hopefully flatten the learning curve for adopting those technologies. 
>
> For example a ITableRidget provides a multi-column table with build-in
> sortability support (i.e. clicking on the table headers) and databinding
> in just few lines of code (i.e. create SWT table control, register table
> control with Riena, bind model to table ridget). This is all done using
> existing Eclipse technologies. Without the Ridget a developer would have
> to learn about TableViewers, learn about Eclipse Databinding, use a
> databinding enabled label and content provider, learn about selection
> listeners (for sorting the headers), store the sortability state of each
> column, manipulate the sortability state of the table ridget based on
> selection events and so on. Much of this stuff may seem trivial to
> Eclipse veterans but can be quite intimidating for Eclipse newcomers.
>   

I agree that much of what you list is intimidating for Eclipse 
newcomers...and don't have any personal experience (yet) with Ridgets to 
evaluate your assertion that they make things easier.   But on the 
surface this seems to overlap a fair amount with what e4 and Platform UI 
are working on (at least the goal of making UI programming APIs 
easier)...so although I don't have any problems with the goals, it still 
seems to me somewhat out of place.

> In short the UI-side of Riena aims to lower the barrier of entry into
> the world of RCP-based clients, by reducing the amount of investment and
> customization required to create a specific application UI (=process
> oriented). This should be good news for people who can buy in into that
> UI style. Note that Riena has more to offer, however I'm speaking for
> the area that I'm most familiar with.
>   

Could you give me an example of a process oriented UI?  Just so I can 
understand what UI/app style is being focussed on?

Thanks,

Scott