I've been developing RCP apps for a while now. I'm not to deep into modeling (what seems to be the hype these days), I focus on ordinary user intefaces and solid business backends. I have been teaching RCP programming for a while, but now I'm back into coding full time.
I do not think I know every secret of the platform, but I am able to build useable applications, I made some progress with RAP and RIENA lately, which I both seem to like.
Teaching RCP programming reminded me always of what it was to me, at least a really hard learning curve. So many times it seemed to be guesswork when something didn't work as expected, a single typo in plugin.xml and the view doesnt show up, forgot the icon for an editor, the editor doesnt show and its all up to you and your google skills to solve the problem. So in the meantime e4 is coming up, what I like is the idea of dependency injection, what I have to get used to, is that modeling is there now, too. But what I truly think should be there is a clear diagnosis option. One should be able to get a clear answer to "why it doesnt work". Even if I think of the OSGI output if there is something wrong in the bundles dependencies. Last time I had a wrong version number in a plugin. It once again was pure guesswork to find the error.
Coding for over 20 years gave me many dislikes, and these days I really wonder how I will manage to do this for the next 20 years. I love coding, and I think that RCP is truly a powerful platform. But it should make some more noise in terms of predictability and it should be easier to understand. I've been teaching old dogs and youngsters and all of them had these moments of "why must this be so complicated".
e4 should be easier to learn and understand, thats what I think should be the primary goal. It must be an attractive platform to developers, no matter what level of experience they have. Every Newbie can learn to to some VBA code with Microsoft Access and even though it has its limitations, thats what eclipse should be too. Easy too learn and with a clear message on the reason of failure.
Last time I had a user report a bug that entries in a table got duplicated when he tried to use my dialog. It was just that I did'nt call TableViewer.cancelEditing in some special usage scenarios. A TableViewer is an all over present interface element. Even after years of using it, I simply didn't know of the necessity to call cancelEditing. When its so hard for me, with so many years of coding, and a true motivation behind it, how does this appear to the newbie ?
In this tutorial we will put together a full application stack for a multi-tenant architecture. We will be using Vaadin and Vaadin-Sprin...
Today I finished my migration of a (small) demo app to the new Vaadin 8 API. First of all: Vaadin 8 has a compatibility layer. Everything ...
Vaadin 8 (currently in beta) comes with a whole new DataBinding API that makes heavy use of the Java 8 Lambda Features. Unfortunately Java...