Community
Participate
Working Groups
I couldn't find a better place for this bug, so we will have discussion here. Jeff just sparked an idea in my mind from a long time ago when talking with Donald Smith about creating a "killer app." Well, in that spirit, I think we should create an application using the Sudoku example that spans across the three environments mentioned in the summary. This would show the power of Eclipse quite well and I think could be cool PR for the website (if the Foundation chooses to advertise it). What are people's thoughts?
So far we have a eRCP and Desktop implementation, who is familiar with RAP and that how that black magic works :)?
My suggestion: keep ECF/multi-user integration in there across all UIs to *really* show off multi-client...and ECF capabilities in that regard.
(In reply to comment #1) > So far we have a eRCP and Desktop implementation, who is familiar with RAP and > that how that black magic works :)? > I had at EclipseCon a tutorial about Server-Side Eclipse (with Simon Kaegi, Gunnar, Martin Lippert). I also implemented an exmple based on RAP. I could give some support or coding for a common sudoku game. (In reply to comment #2) Thats a good idea.
ok, I did some hacking on the plane, here is what I have to report about RAP 1) I don't like RAP's model of how it deals with views. It currently has a custom extension point for defining views (org.eclipse.rap.ui.workbench), it should take the approach by eRCP and simply reuse org.eclipse.ui.views as the fields it declares are practically identical. It's fine to have org.eclipse.ui.views defined in the org.eclipse.rap.ui.workbench bundle. 2) RAP has a radically different way of dealing with Fonts than RCP/SWT (ie., no FontData). How do you code an application that is expected to work with both systems? 3) There's no GC 4) There's no IWorkbenchWindowActionDelegate* Other than that, I have to admit, RAP is so much cooler than I thought. The potential is limitless if we can get the coding models to be more similar. I mean, I think I'll wet my pants when I see the same bundle (Sudoku) working on all three environments.
if anyone could cc RAP experts, that would be great. Gunnar, do you know the RAP team, they are from Innopract mainly, correct?
(In reply to comment #4) > 1) I don't like RAP's model of how it deals with views. It currently has a > custom extension point for defining views (org.eclipse.rap.ui.workbench), it > should take the approach by eRCP and simply reuse org.eclipse.ui.views as the > fields it declares are practically identical. It's fine to have > org.eclipse.ui.views defined in the org.eclipse.rap.ui.workbench bundle. Jochen Hiller talked to the RAP guys and there was an announcement at EFE 2007 that this is going to change for the next mileston, i.e. they will (re-)define the extension points in the org.eclipse.ui namespace and the widget class will be refactored into the org.eclipse.swt namespace. I cc'ed Jochen Krause to answer the other. :)
Jochen, do you have any comments on my concerns? I'm really excited to try to make this happen, it would be the best thing since PDE supported multiple versions of the same bundle :)
Hi Chris, The idea sounds absolutely great! Regarding your concerns: > 1) I don't like RAP's model of how it deals with views. It currently has a > custom extension point for defining views (org.eclipse.rap.ui.workbench), it > should take the approach by eRCP and simply reuse org.eclipse.ui.views as the > fields it declares are practically identical. It's fine to have > org.eclipse.ui.views defined in the org.eclipse.rap.ui.workbench bundle. we have been moving to the org.eclipse.swt (.jface .ui.workbench) package names with M3 and will move to reuse the extension point ids as well in the next couple days. >2) RAP has a radically different way of dealing with Fonts than RCP/SWT (ie., >no FontData). How do you code an application that is expected to work with both >systems? With the move to the SWT namespace we agreed to provide a (better) subset of SWT API, so we will find a way to handle Fonts in the same way for all platforms (but no FontMetrics). We are currently using the factory method for performance reasons (the same font object is reused for all "identical fonts" and shared between all user sessions). Timeframe for this: M4 (in the next six weeks). > 3) There's no GC There is some exiting new stuff in the works, but for now we should strive to implement the sudoku without using GC >4) There's no IWorkbenchWindowActionDelegate* This is in our plan for M5 (July 13), but we may be able to prioritize this if it is a blocker.
thanks Jochen, I'm excited to see RAP evolve.
I think this needs to be moved to the Examples project...
