Community
Participate
Working Groups
I would like to look at updating the RCP Mail example to be more modern. This example is used commonly by people as a launching point. For example, there have been cases where people have taken the RCP Mail example and added things like databinding and other items. Maybe we can look at using the new menu/command story also. Boris, Paul, do you have any comments here?
Michael, Frank, do you think (some of) the code for the data binding tutorial at EclipseCon 2008 should be in the RCP Mail example?
Yes, we could add the code of the EclipseCon data binding tutorial. Would RCP Mail then use data binding per default? I would also be interested in the new command story.
Well maybe. I think there should be both versions. Last week I had a really bad experience with data binding: one of our students writes an eclipse plug-in as part of her diploma thesis. I was reviewing her code and I suggested to use data binding for her simple dialog. She is quite talented but unexperienced. But after 4h of refactoring and explanations she decided that she prefers to do the dialog the old way, because she does not want to have code in her thesis she does not understand. What are the problems: 1. There are so many classes and helper classes in data-binding, it is hard to figure out what to use. 2. Making a simple model send out notification can be quite challenging. class Model { boolean hasFoo; boolean hasBar; String text; // can be set (enabled) if hasFoo or hasBar is set. } She has a lot of fields that enable and disable other fields. We tried to model this using PropertyChangeSupport. Unfortunately, data binding and PropertyChangeSupport want the old and the new value when something changes. To provide this it becomes a major challenge: This is the business logic of the model: boolean isTextEnabled() { return hasFoo || hasBar; } void setHasFoo(boolean v) { hasFoo=v; } void setHasBar(boolean v) { hasBar=v; } But it is really difficult to create notifications for this model because you somehow need to check which calculated fields have changed when you set a value. Not only this, you also need the old value of the changed calculated fields in order to send out the correct notifications. Her original code just called updateEnablement() when the value of any of the booleans changes: void updateEnablement() { textField.setEnabled(model.isTextEnabled()); ... } The buttons use this simple pattern: hasFooButton.addSelectionListener(new SelectionAdapter(){ public void widgetSelected(SelectionEvent e){ model.setHasFoo(hasFooButton.getSelection()); updateEnablement(); } }); Not optimal, but simple and it works. 3. Binding is complicated and non obvious: ObservableListContentProvider contentProvider = new ObservableListContentProvider(); tableViewer.setContentProvider(contentProvider); IObservableSet knownElements = contentProvider.getKnownElements(); IObservableMap[] attributeMaps = BeansObservables.observeMaps( knownElements, EntryPoint.class, new String[] { "foo","bar"}); tableViewer.setLabelProvider(new ObservableMapLabelProvider( attributeMaps)); tableViewer.setInput(fModel.getXxxx()); She said there is no way she would ever figure out how to do this without copying it from an example. And she has a hard time understanding the code. If her professor would ask her to explain this code, she would have no idea what to say. 4. We used WritableList as part of the model. After the model is set up in the dialog, it is used in a job to to calculate something. This caused a "This operation must be run within the observable's realm" error. Conclusion: I think "raw" data-binding is to complicated for average users to be used and understood. And I have to admit that it is still too complicated for me too.
(In reply to comment #3) > 1. There are so many classes and helper classes in data-binding, it is hard to > figure out what to use. Do you have concrete examples? > 2. Making a simple model send out notification can be quite challenging. Yes, because what you describe is no longer a simple model when it has calculated fields. I would recommend using regular properties with setters that notify normally, and overriding firePropertyChange to update the calculated fields, e.g. something like: protected void firePropertyChange(String attribute, Object oldValue, Object newValue) { super.firePropertyChange(attribute, oldValue, newValue); setCalculatedField(getSimpleField1() + getSimpleField2()); } > But it is really difficult to create notifications for this model because you > somehow need to check which calculated fields have changed when you set a > value. Not only this, you also need the old value of the changed calculated > fields in order to send out the correct notifications. Not any more with the above pattern. > 3. Binding is complicated and non obvious: > > ObservableListContentProvider contentProvider = new > ObservableListContentProvider(); > tableViewer.setContentProvider(contentProvider); > IObservableSet knownElements = contentProvider.getKnownElements(); > IObservableMap[] attributeMaps = BeansObservables.observeMaps( > knownElements, EntryPoint.class, new String[] { > "foo","bar"}); > tableViewer.setLabelProvider(new ObservableMapLabelProvider( > attributeMaps)); > tableViewer.setInput(fModel.getXxxx()); > > She said there is no way she would ever figure out how to do this without > copying it from an example. And she has a hard time understanding the code. If > her professor would ask her to explain this code, she would have no idea what > to say. If the above code looked as follows, would you even ask yourself what it does: Util.setUpLabels(tableViewer, EntryPoint.class, new String[]{"foo", "bar"); Util.setUpContent(tableViewer, fModel.getXxxx()); Writing those two methods is trivial. The only reason we don't provide it as part of the data binding framework is that the code would depend on a particular model technology (JavaBeans in this example) and UI technology (JFace viewers). Providing this convenience would come at the cost of having new plugins for all possible combinations of model and UI technologies. > 4. We used WritableList as part of the model. After the model is set up in the > dialog, it is used in a job to to calculate something. This caused a "This > operation must be run within the observable's realm" error. I would argue that this error is actually helpful: It tells you that you haven't thought about potential concurrency problems and what to do about it. It's not that you tried to do a trivial thing and it did not work, it's that you tried to do a complicated thing but get away without thinking about what you are doing. You are asking too much. ;-) If a background job calculates something that affects the WritableList, you should create a realm associated with that background job. Then, use a list binding to have that "background list" be synchronized with a list in the default (UI thread) realm. > Conclusion: I think "raw" data-binding is to complicated for average users to > be used and understood. And I have to admit that it is still too complicated > for me too. With the pattern for calculated properties as described above, and the helper methods for setting up a viewer, is there a chance to change your opinion?
> calculated fields. I would recommend using regular properties with setters that > notify normally, and overriding firePropertyChange to update the calculated > fields, e.g. something like: > > protected void firePropertyChange(String attribute, Object oldValue, Object > newValue) { > super.firePropertyChange(attribute, oldValue, newValue); > setCalculatedField(getSimpleField1() + getSimpleField2()); > } not a very good idea, because this can easily create infinite recursions.... > > But it is really difficult to create notifications for this model because you > > somehow need to check which calculated fields have changed when you set a > > value. Not only this, you also need the old value of the changed calculated > > fields in order to send out the correct notifications. > > Not any more with the above pattern. I think the business logic should not be polluted/mixed with notification crap. If your model is only modified by databinding that keeps track of all observed fields and sends notifications when needed. If any field is set any other field could potentially change. The decorator should figure out itself which other fields have changed and send a the notifications (performance wise, this might not be optimal, but good enough in many simple cases). There should also be a fireChanges() method on the decorator, that can be called by the client if a non date binding method changes the state of the model. Keeping track of changes is very error prone and difficult and should be done by some framework code. I started writing a PojoObvervableDecorator but, well it takes some time, so I pushed it aside.... > If the above code looked as follows, would you even ask yourself what it does: > > Util.setUpLabels(tableViewer, EntryPoint.class, new String[]{"foo", "bar"); > Util.setUpContent(tableViewer, fModel.getXxxx()); > > Writing those two methods is trivial. yes but since it is not there, the raw data-binding seems complicated. To write such code requires already some understanding of data-binding and is not for casual data-binding users... > The only reason we don't provide it as > part of the data binding framework is that the code would depend on a > particular model technology (JavaBeans in this example) and UI technology > (JFace viewers). Providing this convenience would come at the cost of having > new plugins for all possible combinations of model and UI technologies. well this could be done contribution based. instead of another thousand static methods the user would create a Util object (for SWT) that knows how to bind beans or whatever... This object is composed with a strategy that knows how to deal with beans or emf etc.... > I would argue that this error is actually helpful: It tells you that you > haven't thought about potential concurrency problems and what to do about it. once the dialog has finished the setup, it hands the model to the job. The UI will not touch it anymore. We even tried to create a clone of the object but we could not figure out how to clone an object from one realm into another one.... > It's not that you tried to do a trivial thing and it did not work, it's that > you tried to do a complicated thing but get away without thinking about what > you are doing. You are asking too much. ;-) It is very trivial. you create a model, edit it using the UI and then hand it to a job. > If a background job calculates something that affects the WritableList, you > should create a realm associated with that background job. How do I create a realm for a job? The data was actually given to org.eclipse.search.ui.NewSearchUI.runQueryInBackground(ISearchQuery). How do I create a real for that? > Then, use a list > binding to have that "background list" be synchronized with a list in the > default (UI thread) realm. This is an example of the complication data-binding adds. By being "clever" and protective, it makes it difficult to do simple things. Simply creating a (recursive) copy does not work for WritableList. > With the pattern for calculated properties as described above, and the helper > methods for setting up a viewer, is there a chance to change your opinion? I am convinced anyway -- the question is if a newbie programmer can understand all this...
*** Bug 261419 has been marked as a duplicate of this bug. ***
We actually have code from the EclipseCon tutorial for this, it just needs to be fed through the IP process. Any volunteers?
I volunteer! I've always dreamt to fill a CQ :p
Great! Examples should be licensed under the EDL. See http://www.eclipse.org/org/foundation/boardminutes/2008_11_19_Minutes.php and http://www.eclipse.org/org/documents/edl-v10.php. This means that we (1) need to relicense the original code under the EDL and (2) get the newly contributed code reviewed. Here is what needs to be done as far as I can tell. You don't have to do everything yourself, but it helps to have someone who drives and coordinates things: - check with the Eclipse Foundation on what to do (are these steps what we need to do?): license (at) eclipse.org - Figure out where the current RCP Mail example lives in CVS - Look at the CVS history of the current example. Who were the contributors to the original example? - I am hoping that all contributors were IBM employees at the time of the contribution. This would mean that IBM owns the copyright and can relicense. - Find out from license (at) eclipse.org what the process for relicensing is - do they know who in IBM would have to be involved? - Attach the new code contribution to a bug (probably this one). It is currently in a SVN repository run by Kai Toedter. - Get the authors of the new code to confirm that they authored it, and that they agree to license it under the EDL. The authors are Kai Toedter, Frank Gerhardt, Michael Scharf, Paul Webster, Francis Upton, and myself. - File a CQ for the new code. Should be fun :-)
(In reply to comment #8) > I volunteer! I've always dreamt to fill a CQ :p > Hi Ben, If it makes things easier I could create an svn account for you. Please contact me directly (kai.toedter@siemens.com). Meanwhile take a look at http://max-server.myftp.org/trac/rcp-mail
Howdy guys. I want to do this for 3.6 (M2 preferably) Is it possible to get the code and start a CQ?
One option is to also donate the example code to the Examples project (www.eclipse.org/examples) However, I still want an updated template.
Chris, The latest source base is still available at my svn server https://max-server.myftp.org:444/svn/rcp-mail/trunk/projects/steps/rcpmail-99 see also http://max-server.myftp.org/trac/rcp-mail I suggest the following process: - All rcp-mail committers (Boris Bokowski, Francis Upton, Paul Webster, Michael Scharf, Frank Gerhardt and I) agree on a disclaimer (Copyright, EPL, Contributors) - You, or another PDE committer transfers the code base to PDE - The original rcp mail 2.0 committers could go through the PDE committer process, if they want. This makes sure that the new template would be maintained properly. I would be great if we could have rcp mail 2.0 in 3.6!
Chris, the original RCP Mail template generates code without any license headers. Since RCP Mail 2.0 is a derivative work of the original RCP Mail example, there is more that needs to be done, see also comment 9.
We have the final code for RCP Mail 2.0 but never touched the wizard and code generator yet. For the final code we still have a few outstanding clean-up todos like renaming the packages. We kept the old package(s) so that it was easier to relate the code to the original RCP Mail. There todos are in Trac.
You also need to prepare the infrastructure as described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=265231 Quote: --------------- I believe it is also necessary to make a copy of templates_3.3 to templates_3.5 and to patch PDETemplateSection method getDirectoryCandidates() to consider the new template directory. --------------
Removing M2 milestone
Are people willing to donate the RCP mail 2.0 code to the Eclipse Examples project?
@Chris I think that the Examples project would be a good home for the RCP Mail 2.0 RCP application. On the other hand, if we want to have a new RCP Mail 2.0 template, somehow this code base has to be shipped with the IDE then. I guess the additional template/generating code could still be hosted by PDE. But we would need an OK from all other contributors: Frank Gerhardt, Michael Scharf, Boris Bokowski, Paul Webster and Francis Upton.
FWIW, I am in favour of moving the RCP Mail example to the Examples project.
I believe the most critical part is to adjust the PDE templates as new users always "do as they see". My impression is that the "big bang" approach, e.g. we update the most complex example first, does not work. Therefore I would suggest: 1.) Create the infrastructure to have new templates in 3.6 (by making a copy of templates_3.3 to templates_3.6 and to patch PDETemplateSection method getDirectoryCandidates() to consider the new template directory. 2.) Update "RCP application with a view" with commands (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=265231) 3.) Gradually update the Mail examples to an improved template while having the full example (if possible) already in the example projects. I fear that if we don't do the improvements of the templates that the Eclipse PDE templates will still stear new users in the "use actions" direction which causes a lot of traffic on the newsgroups.
You can certainly have my +1 :-) PW
+1 from me, this will be great, thanks for the work!
I created bug 290029 to track the RCP Mail 2.0 contribution to the Examples project.
Sorry for being pedantic, but I believe we need to pay attention to licenses this time (note that when you use PDE to generate the RCP Mail example, it will have no license headers at all!) See comment 9: > Examples should be licensed under the EDL. See > http://www.eclipse.org/org/foundation/boardminutes/2008_11_19_Minutes.php and > http://www.eclipse.org/org/documents/edl-v10.php. This means that we (1) need > to relicense the original code under the EDL and (2) get the newly contributed > code reviewed. Since then, I have learned a little more and now believe that the example code should be dual-licensed under EDL and EPL. The reason for the EDL (as one of the most permissive licenses around) is that it allows clients to start with the RCP Mail example and do with it what they want, without having to contribute changes back. I believe this is important for example code like this; anectdotal evidence suggests that a good percentage of today's RCP apps were started by having PDE generate the RCP Mail example. Why dual license with the EPL as well? This is so that any piece of the example can be consumed easily by projects at Eclipse that are licensed under the EPL. Wayne, does the Examples project have a policy for this? It would make sense to me if everything under the Examples project were dual licensed.
I think dual licensing is fine, we should discuss this in bug 290029 as we setup an initial contribution and get the authors to agree to the terms of the new license.
A (somewhat) related bug would be bug 278078.
(In reply to comment #25) > Wayne, does the Examples project have a policy for this? It would make sense to > me if everything under the Examples project were dual licensed. The Examples project has no formal policy. I have a "to do" on my list to dual license everything that is currently there.
*** Bug 293837 has been marked as a duplicate of this bug. ***
Created attachment 150990 [details] Use commands for RCP mail example As this is flagged 'helpwanted' and the biggest problem about the RCP mail template seems to be using actions instead of commands, I decided to fix this separately from the RCP Mail 2.0 issue as suggested by Lars in comment 21. I hope this is helpful. I think it makes sense to keep the template a lot simpler than a full RCP mail example. Which would be great to have in Eclipse examples. Here is what I did with the attached patch: - Added TARGET36 to org.eclipse.pde.core and bumped versions to 3.6.0 (I hope this is the correct way to do this - what is it about the .100 as minor version number for 3.4/3.5?) - Updated template description with "since 3.6" remarks to be backward-compatible - Added menu contributions to MailTemplate class - Updated key bindings to use M1 instead of CTRL - Copied templates_3.3/mail to templats_3.6/mail (WARNING: you need to copy the bin folder yourself - CVS said it cannot handle binary files for patches - WTF!) - Replaced Actions with Handler classes in templates - Removed ActionBarAdvisor in templates Tested with I20091029-0840 and Java 1.4. This is my first somewhat bigger patch to an Eclipse project (I picked an easy bug to practice ;). If I did anything wrong/could do anything in a better / more efficient way, I'd be very thankful for your suggestions.
Cool! I'll look at this for M4 I think this template is valid for 3.4+ eclipses, right?
Thanks Ralf!
At Eclipse Summit I talked with Wayne about it. We should support 3.5 and 3.6. I would also like to add e4. My plan is to let the gang of four read though the code once (and only once) more, and then submit it to CVS. Once it is in, we can still beatify it further.
Created attachment 151412 [details] Use commands for RCP mail example (starting with Eclipse 3.4) zx, you're right. By mistake, I assumed that this should not be changed for older versions. I created a new patch and tested with a RCP 3.4 target.
I have been (un)lucky enough to have been selected as the legal contact since I was the one that opened bug 278078. Before I get to the snippets code from UI, I would like to get the RCP mail example authorized for dual-licensing for starters. I need to get back to legal as to the number of copyright holders in this code. Now based on comment 13, I understand that the following people have contributed something to this example. Is there anyone else? Boris Bokowski (bbokowski, IBM) Francis Upton (fuptoniv, Oakland Software) Paul Webster (pwebster, IBM) Michael Scharf (mischarf, Wind River) Frank Gerhardt (Gerhardt Informatics) Kai Tödter (ktoedter, Siemens) Frank, are you a committer? If yes, what is your user name?
I just tried the RCP Mail 2.0 application as downloaded from http://max-server.myftp.org/rcp-mail/download/rcpmail-downloads.html, looks cool! What is the set of plug-ins proposed for inclusion as Eclipse example? rcpmail-99? The rcpmail.contacts-14 as well? btw, in rcpmail-99 the dependency to "org.eclipse.core.runtime" was missing for me, resulting in: The type org.eclipse.core.runtime.Plugin cannot be resolved. It is indirectly referenced from required .class files NavigatorLabelProvider.java /rcpmail-99/src/rcpmail line 46 Java Problem
(In reply to comment #31) > I think this template is valid for 3.4+ eclipses, right? can you please retry the template patch, I updated it to be compatible with 3.4+
Comment on attachment 151412 [details] Use commands for RCP mail example (starting with Eclipse 3.4) Created separate bug 298391 Use commands for RCP mail template (starting with Eclipse 3.4)
Is there any ongoing work on the required legal work to get the RCP Mail 2.0 code into the RCP examples? I guess this application would be a good starting point for examples how to port RCP applications to e4 because it's a bit more complex and makes use of the common navigator. What exactly is the contribution to be tracked by bug 290029 - is it http://max-server.myftp.org/trac/rcp-mail ... rcpmail-tutorial-2.0.0.v200904291506.zip ... steps/rcpmail-99 ?
Boris, is there any chance to get this into 3.6 or is this impossible because of the API freeze? What are the dates not to miss for 3.6[.1]?
(In reply to comment #40) > Boris, is there any chance to get this into 3.6 or is this impossible because > of the API freeze? What are the dates not to miss for 3.6[.1]? It can't be committed until it passes IP review. Unfortunately, I haven't really been on top of this.
(In reply to comment #40) > Boris, is there any chance to get this into 3.6 or is this impossible because of > the API freeze? What are the dates not to miss for 3.6[.1]? As this is an example project which is not to be shipped in any build and only sits in CVS for people to check out, shouldn't it be possible to commit this at every point in time? (In reply to comment #41) > It can't be committed until it passes IP review. Unfortunately, I haven't really > been on top of this. I guess this means CQ process, has this already been started? Anything I can do to help with this? About text in the rcpmail-99 says: Contributors: Frank Gerhardt, Michael Scharf, Kai Tödter, Boris Bokowski, Francis Upton, Paul Webster This software is licensed under the Eclipse Public License v1.0, see http://www.eclipse.org/legal/epl-v10.html The icons (http://www.famfamfam.com/lab/icons/silk by Mark James) are licensed under the Creative Commons Attribution 2.5 License, see http://creativecommons.org/licenses/by/2.5 Is CC content compatible with EPL or should we strip those? Could anyone of the original authors please define what projects exactly comprise "RCP Mail 2.0"? I guess it would help to clarify about which code we're talking about here exactly, or did I miss that information somehow?
(In reply to comment #42) > As this is an example project which is not to be shipped in any build and only > sits in CVS for people to check out, shouldn't it be possible to commit this at > every point in time? Yes but the legal team still needs to look at it. > (In reply to comment #41) > > It can't be committed until it passes IP review. Unfortunately, I haven't really > > been on top of this. > I guess this means CQ process, has this already been started? Anything I can do > to help with this? I've forwarded you two different email threads. Besides Chris and Wassim, I believe Nick Edgar also had a hand in the original RCP mail so they'll all need to confirm on the relicense bug request (as far as I can tell). I'm a little iffy about Kai's notebook icon though it wasn't entirely clear to me just where the source of that icon is so perhaps he could clarify on that.
Both, the e4 contacts notebook icon and the RCP Mail 2.0 mail icon (on splash screen and about dialog) came from an direct import within Microsoft PowerPoint 7 (clip art). If you search for "mail" in PowerPoint you will find the icon. There is no copyright information available, I guess theses icons are totally free for any use.
Found out, that the mail icon is from PresentationPro: http://www.presentationpro.com/powerpoint-design-4681-email-letter-01-blue.aspx?catID=160&pagesize=24&color=Blue&ProductTypeFilterID=0&Sort=pop Since this is imported through PowerPoint, I guess it is a free sample. If not sure if we can use it, I suggest to replace it by a self made icon.
Created attachment 163316 [details] mail icon +1 for replacing with something that's 100% ip-clean. propably there is something about the clipart in the software license agreement. I justed played around with Illustrator for 5 minutes and created a mail icon that also uses the Eclipse color palette :) License is EPL/EDL :)
Created attachment 163317 [details] rcpmail.ai original Illustrator file
Created attachment 163368 [details] rcp mail 2.0 splash screen Based on Ralf's mail icon I created a new splash screen
Created attachment 163370 [details] rcp mail 2.0 about image Based on Ralf's mail icon I created a new about image
Before we can file the relicensing request we need to find out who wrote the original RCP Mail template. I opened bug 307925 to clarify this. I already changed the project to use the new images and will open a bug for the relicensing request as soon as I have a verifiable list of the authors of the original template code.
Bumping to 3.7
Is getting RCP Mail 2.0 incorporated into the SDK as a PDE project template close to completion? It seems to have been stalled in legal approval for some time ... unless there are other issues I've missed. I ask because I am looking for a place to showcase Susan's work on simplified RCP update UI. The RCP Mail template would seem to be a great place to do this, but, as you have all pointed out in this bug report the current RCP Mail template is very out of date.
AFAIK there isn't being any work done on the integration. There was some concern over the legal issues, but I believe most contributors have given their ok on bug 307925
(In reply to comment #53) > There was some > concern over the legal issues, but I believe most contributors have given their > ok on bug 307925 At the moment, I think we're missing Nick and Cherie's ok. Also note that we're talking about the mail projects here and not the templates. Someone would still have to do the work to morph the projects into reusable templates.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
