Community
Participate
Working Groups
The user should be able to create a rich client application just as easily as a Java project or a Plug-in project. The New Rich Client wizard would be similar to the New Plug-in wizard, and automatically generate the plug-in class, the Application (IPlatformRunnable) class, the Perspective (IPerspectiveFactory) class, and the Workbench Advisor (WorbenchAdvisor) class. It should also have templates to do things like add a view, add a menu, and so forth.
Created attachment 8260 [details] Contribution of an RCP wizard. This partial implementation adds a Rich Client Project option in the New Project wizard under the Java category. It uses the projectGenerators extension for templates and adds an rcp=true/false attribute since not all templates are applicable for rich clients.
Created attachment 8261 [details] RCP wizard under the Java category. I put it under the Java category because it's just another way to write general purpose Java programs. Inside, though, it uses PDE functionality.
Created attachment 8262 [details] Create RCP wizard Note all the messages have been changed for rich clients.
Created attachment 8263 [details] RCP project structure Same as the plug-in project structure with some message changes.
Created attachment 8264 [details] RCP Plug-in content This is where the user defines the content for the main plug-in of the RCP application. The Name says "Application" instead of "Plug-in".
Created attachment 8265 [details] RCP Templates The RCP templates screen gets it list from the projectGenerators extensions but only shows the ones that specify rcp="true" because some would not be appropriate for RCP apps.
Thank you Ed for the patch. My first reaction to the images attached though is that a Rich Client project is a variation of a plug-in project. Therefore, I don't feel that there is a compelling reason to give it its own wizard. The resemblance is uncanny to the current plug-in project wizard. Since we are planning to open up the templates and allow people to contribute their own (target 3.0M9) (see bug 45682), we were certainly planning on adding more attributes to the template schema to specify if it's rcp-friendly or not. Another flag might be to indicate if the schema requires a UI or not. So at the end of the day, I definitely see us enhancing the "Templates" page of the current Plug-in Project wizard to have several options. For example, we would present three options to the user on that page: 1. Create a UI plug-in using one of the templates 2. Create an RCP project using one of the templates 3. Create a non-UI plug-in using one of the templates Selecting of one of the three options will show the corresponding templates in the viewer below. Depending on which selection is made, we generate the appropriate template and Java classes.
Well, the resemblence is uncanny because it's the same code :). The Rich Client wizard is almost identical to the plug-in wizard except for some messages, the name of the plug-in, and the templates at the end. Although you and I know that a rich client is a variant of a plug-in, I was hoping to shield (or at least, gradually reveal) some of that knowledge from the general Java programmer. I sat down to write a document for the general Java programmer about how to write a Rich Client application. You can see a draft at http://prdownloads.sourceforge.net/eclipsepowered/Eclipse_ch_rcp_intro.pdf? download . When I was done with just the introduction, I had something like a 30 step process to create a blank window. So I thought, this is ridiculous and started thinking about a wizard. When they start, the developer is not trying to develop a plug-in; they're trying to develop a Java application that uses the Rich Client Platform. This way I thought we could let them find the functionality easier without a lot of work.
I do agree that a wizard is a better solution that a 76-easy-step process ;-) However, I'm always very resistant to presenting variants of the same thing as separate wizards, because it will give users the impression that they are separate and distinct entities, which, in this case, are obviously not. That is also the reason why we removed the new bundle project creation wizard, for instance. A bundle, in Eclipse, is a slightly differently structured plug- in, and that is why we should take care of it in the plug-in project wizard, and should not be presented as a separate entity. All the two wizards did was confuse users on which route to take. So you might be shielding the user from the plug-in concept during the creation of the project, but what happens when the project is created. For everything else he needs to develop/test/deploy the RCP application, he will need to deal with plug-ins. Since Eclipse is/was/always will be in the business of plug-ins, and RCP app is just a variant of it, we should treat it like that consistently and from the beginning (i.e. project creation) to the end (deployment).
Dejan, this all feels like a deja vu. Back in 2.0, we had to provide tooling so that a user can create, test and see his first plug-in up and running in less than 10 minutes. Now, we have to provide tooling so that a user can create, test and see his first rich client application up and running in less than 10 minutes.
I would like a wizard that will create a complete RCP application in 10 minutes so that I can go diving for the rest of the RCP project term.
Here are my thoughts: - this is important -- anything we can do to decrease the learning curve and barrier to creating RCP apps is good - having it work similarly to the regular plugin wizard, or having it just be an option within the regular PDE wizard, is important - I don't see the need to gloss over plugins Thanks, Nick
RCP is built from plugins so people build plugins. But people also need help branding etc. Tooling folks don't need this as much as they often fit into an existing system (i.e., have little branding) or are shipping a big product (i.e., someone else figures out the branding). With RCP it should be possible/easy for someone to create a fully branded (splash, config, ...) set feature/plugin set. I may be possible/reasonable/best to knit this into the exiting plugin wizard with some extra options (e.g., would you like branding with that?) As long as developers can get the job done.
*** Bug 64075 has been marked as a duplicate of this bug. ***
Moving to 3.1
An interim progress report: In Tuesday's I-build, the New Plug-in Project creation wizard will have a new "Would you like branding with that?" section. This section will allow the user to: 1. Define the product name 2. Associate an existing application with the product OR enter the name of a new application. In the case of a new application, PDE will also generate a template for the Java class that implements IPlatformRunnable. 3. Generate default window/about images, a splash screen, and templates files (about.ini, about.properties, plugin_customization.ini). With respect to images, the user can either choose to generate defaults or can browse for existing images on disk and we would just copy them into his new plugin project. We will not generate config.ini as this file is generated by PDE upon launching. When it comes time to deploy the product later on, we could generate one then. Two more items will have to be completed before we declare (initial) success on this bug report: 1. The list of templates, which is now a flat list, should become a tree with two parent nodes (RCP and non-RCP) to separate the templates and make it clear which ones are appropriate for RCP development and which are not. This will require adding an extra attribute for the template extension point to indicate if a template is RCP-friendly or not. 2. The contextual launch of a runtime workbench should become sensitive to the current workspace selection (much like the behavior with the JUnit Plugin launcher). Right now, the default behavior is to always launch with all the workspace and enabled external plugins. This behavior should be changed as follows: If the current workspace selection is a plugin project whose plugin.xml declares a product, then we launch with this plugin and all its pre-reqs only, and with this plugin's product id as the eclipse.product setting, etc.
I don't think that creating a new plug-in project and selecting an option to add branding is a natural way for someone to create a rich client application. For one thing, a product and branding, while common, is optional in an RCP app. The use of the application extension point is the defining characteristic of an RCP app, not the use of the products extension point. Also, the term rich client needs to be more visible in the new project wizard since it will be a major thing people want to do with the platform. I'm thinking something like: Java > Simple Java application, Java > SWT-based application, and Java > Rich client platform-based application. Or maybe under an "Eclipse" heading instead of Java. Editing config.ini should probably be done with a new page in the Plug-in Manifest editor, similar to build.properties. Also if the wizard is going to create some template files I think it needs to generate the config.ini file that refers to them. It shouldn't be generated upon launching unless there isn't one already. Instead of RCP vs. non-RCP templates I suggest IDE vs. non-IDE templates. RCP is the base so it makes sense and is more flexible to define other things (like IDE, JDT, AJT, etc.) as optional add-ins to it. The extension point would indicate if a template requires some special components (i.e., IDE) or not.
As with every other feature, we may have to go through several iterations to get this one right, but we shouldn't dismiss the first iteration before it makes it into the I-build ;-) Now for a rebuttal: I do agree that branding is not mandatory in RCP and that is why it is only option. We ask you if "you want branding with that?". I don't think it is awkward to have the branding question in the wizard. Jeff and I had a real life situation when such a feature in the wizard would have been just what the doctor ordered. I actually think the current flow in the wizard is pretty good. It is not intrusive on people who are not creating an rcp app, ie. they don't see extra unnecessary pages. For people who are creating in an RCP app, they have a page to create the application and add branding, should they want to. I still don't see the need to create a whole new set of wizards for RCP that are >98% identical to the current PDE wizards, just to change a couple of labels here and there. Before you know it, PDE would have 62 wizards. To use one of your quotes: "The use of the application extension point is the defining characteristic of an RCP app". That is exactly my point and the reason why we don't need a new RCP app wizard. It is just a plugin with an applications extension. As for the config.ini: I actually have mixed feelings about that. I really don't see the need to expose people to yet one more file and have them manage it. Two reasons: 1. They can't use the config.ini as-is to test their plugin. As you import/delete plugin projects from your workspace during development, the URLs of the plugins in the config.ini consistenly change. That is why PDE generates a new config.ini on the fly with every launch. This task should remain completely managed by PDE as we know what is best for the user and it would be a pain if the user had to manage it with every change he makes. 2. The user will need a config.ini only at deployment time when he packages the product. In the deployment wizard, we will take the list of plugins, branding info etc, and generate a config.ini file for the user. Again, I don't see a need here for them to have to do it/manage it manually. As for the grouping of templates (IDE vs. non-IDE) etc., this is a good suggestion, and it is also one of those examples where we have to put it in the build and see how people like/dislike it and take it through >=1 iterations if needed.
I very much agree that this is a case of try it and see. We can postulate all we want but you really have to get something, criticize/praise and iterate. I also agree that we do not want to have too many wizards. The link between branding and plugin is somewhat troubling however. Is there a reasonable way that we can surface "product" in all of this. Perhaps one new wizard which is "New Product" (note that this is not RCP or IDE specific). It would allow people to identify the plugin they want to use to contain the product definition (or go into the new plugin wizard if necessary). They can also define the branding as needed and have the build.properties etc updated. And, perhaps optionally have a config.ini generated. Now that the notion of product is surfaced, on can think in terms of launching the product. In the launch config we already can choose a product. This would then imply using the config.ini defined in the product they have identified. This feels more natural and closer to the model we tell users about. It also addresses some of the roundtripping issues raised elsewhere. In particular, if there was a "Product editor" (as mentioned in other bugs) then the development lifecycle is clear. Generate with the wizard, edit with the editor.
Here is an update: 1. The new plug-in project wizard will not contain any "productization" aspects. This issue will be addressed separately in bug 73818 2. Contextual launch of a runtime workbench will also be addressed separately in bug 73820. As for what the wizard will look like in tomorrow's I-build: 1. On the second page of the wizard, there will be an option asking the user if they are creating a rich client application. If so, they enter the id and the class name of the application. When using this option, PDE will generate a minimal, yet ready-to-run application, which when run, will bring up an empty window (i.e. the result would be the same as Ed's Tutorial Part II and the groundbreakingly blank window that Nick so proudly demoes ;-) 2. When the RCP option is selected and the user clicks Next, the template page will only be populated by wizards that are declared as RCP wizards. We added a new attribute (rcp) to the pluginContent extension point. Right now, the only template available is a hello world template. For a more sophisticated template, bug 60000 would be used. Closing this bug report, as the RCP enabling support is now there and it's so nice.
I installed 3.1I20040914 and tried this out. Can I comment on it now? :) The title, initial size, perspective name, toolbar/coolbar setting, etc. should be an option somewhere. It feels like a template is being used even though it's not. Hmm... maybe an "RCP application" template would be a better fit than hardwiring what you're trying to accomplish here. I still really don't think that New > Project > Plug-in Development > Plug-in Project is a natrual thing that a user will discover when they're trying to create a rich client application. I understand the arguments about how it's really just a plug-in and you don't want new wizards but it seems like there could be some compromise that would satisfy my intuitive/discovery concerns and your code share concerns. [Next I'm eagerly awaiting the launching support. Naiive user hat on, first thing I tried was right click on the project > Debug > ?. The only thing that halfway made sense was picking run-time workbench, but that just gave me a list of the existing workbenches that I had used before (which has always struck me as odd).]
>it seems like there could be some compromise that would satisfy my >intuitive/discovery concerns and your code share concerns. what is that compromise? I am not budging on this one because I have yet to hear a convincing argument that shows an RCP app as a drastically different entity from a plug-in that it warrants a new wizard. >The title, initial size, perspective name, toolbar/coolbar setting, etc. >should be an option somewhere. What toolbar/coolbar setting? all we're doing here is just creating a blank window. As I said before, a complete RCP template where you can set stuff would be addressed in bug 60000. As for setting the title/size of the window, I went for simplicity here and assigned default values. Not sure it would be incredibly necessary to add a number of options to the wizard to customize a blank window. Changing these values after-the-fact is trivial. When creating templates, we typically give people options mainly to customize our code gen, e.g. do you want a tree viewer or a table viewer? window size is certainly borderline. I'd rather make the wizard simple than overload it with a load of minor options to create a blank window. And don't get me started on the perspective name thing.. :-) Do you really want to expose the word 'perspective' to your delicate Java users right off the bat? Let alone ask them for a name for it? They will get to the perspective concept soon enough when they start looking at the code. Long story short... We're going for a minimum number of bells and whistles (e.g. options) when creating a minimal RCP app. Templates with options is the topic of another bug.
I'd prefer if you change your templates to the following: public class SampleWorkbenchAdvisor extends WorkbenchAdvisor { public String getInitialWindowPerspectiveId() { return SamplePerspective.ID_PERSPECTIVE; } ... public class SamplePerspective implements IPerspectiveFactory { public static final String ID_PERSPECTIVE = "rcp.samplePerspective"; @@@@ You should get the user into the habit to use constants right away. @@@@ Also the Advisor and the Perspective should be named like the Application: <Name>Application <Name>WorkbenchAdvisor <Name>Perspective
I also agree with Ed on having a seperate wizard (if only in name). The wizard would create a "RCP Project" rather than a "Plug-in Project". A "RCP Project" would have three natures: org.eclipse.pde.PluginNature org.eclipse.jdt.core.javanature org.eclipse.pde.RCPNature The third nature would/could expose RCP specific actions (build executable binary for example). Also, a wizard page with branding options should be added. @@@@ I think implementation wise you could/should use the same wizard code base (perhaps with a RCP flag) but presentation wise they should be two different entities. If I'm new to Eclipse and read about RCP I'd naturally look for "New RCP Application" somewhere. The same "duplication" has to be done for a "Creating a RCP Application" cheat sheet by the way.
Will take suggestions in comment #23 into consideration. >If I'm new to Eclipse and read about RCP I'd naturally look for "New RCP >Application" somewhere. Perhaps, the literature/songs/poems written about RCP should tell people that RCP apps are based on plugins (ie. no conceptual leap required to develop RCP apps). So as for an "RCP" project/wizard, I'm still not budging. >Also, a wizard page with branding options should be added. We already tried that, but didn't receive good reviews (see comment 19) So we will address branding as a separate step (post-creation) in bug 73818
Created attachment 15769 [details] new entry point Here is my latest attempt at a compromise. We keep the one wizard for reasons listed above. Yet, we make the entry point to the wizard more expressive and indicative with a new label. Soliciting for feedback. Do people hate it? like it? or are people ambivalent? indifferent?
Is 'ambivalent' a word? :-) sounds right though.
What about two entries: One for Plug-in and one for RCP? Both entries would open the same wizard. Having distinct entries would open the possibility to change/add/seperate them in the future. @@@@ If there should only be one entry then there should be no blanks surrounding the slash -> 'Plug-in/Rich Client Application'
Yes, "abivalent" is a word. "characterized by a mixture of opposite feelings or attitudes" This pretty much captures my situation here. Assuming that what this really does is generate an applicaiton extension and a stub applicaiton class... In the interest of simplicity and promoting the model, it seems that just New - > Plugin and then a checkbox in the wizard to get an application (e.g., "would like an application with that?") is clear, does not muddy the overall model and gives users what they need/want. I am much more keen on "product" definition etc
Eww. Well, you know I'm not going to be happy until I see Rich Client with its own entry not under Plug-in Development. Most people won't come in the wizard looking to build plug-ins. They might not even see the plug-in category if the capabilities are not set up for it. Think of somebody starting Eclipse for the first time who doesn't know anything about Eclipse except maybe they read a magazine article or saw a co-worker using it. Most likely they want to build a new plain Java application, a Rich Client application, a Web site, or a J2EE application. Or they want to convert some project they already have.
Ed, you're declining an offer that is much better than what you are asking for. If the "New Plug-in Project" label is changed to "Plug-in/Rich Client Application", the words 'rich' and 'client' will have much greater visibility than being buried under a Java category. The new plug-in wizard is a UI capabilities hook, so it appears on top of the list (second in the screenshot), uncategorized, regardless of what capabilities are turned on/off.
the deal is off the table ;-)
Then the Rich client wizard entry would likely need to be up there at the top too. I'm not sure that's a scalable solution (putting all the capability hook entries at the top) but that's a separate issue. Guess I'll have to wait for the after-Thanksgiving clearance now. :)
Re comment 30... My proposal (of course, not negotiated with Wassim :-( is for a New->Product wizard. Given the definition of that the RCP application wizard is doing, I don't think it is what your (Ed) user wants. They want something which helps them define, implement, build and deploy the whole enchillada (sp?). Splash screens, launchers, applications, icons, ... The application extension point is a mere implementation detail that should be swept as far under the covers as possible. With that in mind, the wizard being proposed here is precisely aimed at the user who DOES know they want a plugin and that they implement applications in plugins etc. The naive, new to Eclipse, would-be RCP king-pin needs the higher level help.
If you recall, we initially tried mixing the RCP project creation step with the productization aspect of RCP and the result was not well-received. (Refer to comments above). While the productization is the more interesting problem, it is also the more challenging as we still need to define user scenarios/workflows determining when the user actually wants to create a product, how often he needs to edit the product configuration, etc. Worrying about splash screens, images, etc. at the time when we are creating the application itself seems premature. That is why the project creation and the making of a product should be separate steps. (Refer to your own comment 19) In any event, the product aspect of this issue is being tracked in bug 73818. As for this feature whose objective is to give users a jump start on creating an RCP app: While I appreciate everybody's input, it's clear that we are deadlocked and we can't keep having the same conversation over and over again. It's like watching Crossfire on CNN every afternoon ;-) I want to put closure on this topic, as we have bigger fish to fry in the RCP realm. We will not have two identical wizards. For reasons why I (and others) believe is the wrong approach, refer to the lengthy discussions above. I put the onus on the RCP literature to ensure that readers know RCP apps are based on plugins. If the message is not being clear at that level, then we have much bigger problems that no 2 PDE wizards can solve. The contextual launch support mentioned in comment 21, of course, has been in since 3.1 M2. Creating a detailed customizable template will be addressed in 3.1M4 in bug 60000. Branding and product configuration will be addressed in bug 73818. I will close this defect as the changes made to the existing wizard is how we are going to address the RCP app creation issue. If you have suggestions on enhancing the current wizard, please open separate bug reports. If you still feel strongly that we need two wizards, one under java, one under bla bla bla, ... then you can reopen this defect. In which case I will break the dependency of the big PDE RCP plan item (bug 71131) on this bug report, as I don't see us going down that route.
Sounds good, thanks for your work and patience on this.
