This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
issue for UI Review Process http://wiki.netbeans.org/MobilityCustomComponentProjectSupport affected Main UI Elements: * New Project wizard * New File Wizard see http://wiki.netbeans.org/MobilityCustomComponentProjectSupport#section-MobilityCustomComponentProjectSupport-AffectedMainUIElements
See also feature planning issue 135122
Thanks for filing the UI review request! A few questions for the beginning: - What's the build result of the component project? Is it a JAR file, nbm file or something else? - The resulting components can only be used in NetBeans, right? - What happens if the user runs a component project? - What happens if the user debugs it? - Could there be multiple components inside a single project? - What happens if the user runs a project with multiple components in it? I'll try to provide recommendations for the main UI elements as soon as I better understand the whole workflow.
- What's the build result of the component project? Is it a JAR file, nbm file or something else? New NetBeans project of 'NB Module' type. Prepared project is unzipped, updated and opened in IDE. - The resulting components can only be used in NetBeans, right? Yes. - What happens if the user runs a component project? * Prepared zipped project template is unzipped and modified according to values selected by user in wizard * library descriptors for libs selected by user are created and registered in project (ordinary Java SE Library) * Custom mobile component classes and other files are created and registered in project - What happens if the user debugs it? Debugging is skipped for now. It is planned as Action available in created Custom Component Project. - Could there be multiple components inside a single project? Yes. They can be added on "New Project Wizard Step 4 - Add Component Descriptor". And after project is created, can be added using "Custom Component" file type in "New File" wizard - What happens if the user runs a project with multiple components in it? Do you mean a Nb Module Project, created as a result of "New Custom Component Project" wizard? And this project will have several registered custom components. After building and installing module project into NetBeans, all custom components should appear in Mobile Visual Designer palette.
Sorry, I have misunderstood 2 questions: - What happens if the user runs a component project? Created and registered Component will appear in Mobile Visual designer palette. - What happens if the user debugs it? Result is the same as for existing Nb Module actions "Install/Reload in target platform", "Install/Reload in development IDE". But Result IDE will have one extra tab (as it happens if IDE is started with "-J-Dvmd.structure.show=true" flag)
Thanks for answers! Why do we need this special project type at all? It seems to me that what is the user really creating is a Module (project) and a bunch of components in it that will be installed into palette when the user installs the module. Wouldn't it be enough if we add the component file template into the Module project?
On planning step there was idea to extend Nb Module Project, but update it a little (filter actions, add specific actions atc.) But Nb Module Project doesn't provide enough possibilities to modify it. So now the only remaining idea of Custom Component Project is to take user through all necessary wizards at once. Karol, your opinion? cc-ing to kharezlak.
There is few reasons for it. First of all this module should gives user possibility to create all necessary files in one event just like we have in the New Project Wizard. It should be clear that they are creating new Mobility Custom Components not playing with API support. For many Jave ME developers dealing with Netbeans API (API Support) could be very frustrating experience so I want to guide them though process of creating of the new project as much as it possible. Users should be aware of all necessary steps to make Mobility Custom Components project works. Also we want to have control over project template. It gives us flexibility so we could add additional things to it later on and make sure that user will have less occasions to make mistakes using it.
In my view the Custom Component project is nothing else than a narrowed NetBeans Module project. It doesn't hide NB api development, as the user needs to know the mobility module API at least. Is that correct? At first I actually thought this was going to create some sort of standardized mobility components similar to JavaBeans. In fact it's NetBeans specific which isn't obvious and may be misleading. Therefor I propose to enhance the NB Module project with the custom component template. If the user creates it, add all required libraries to the project automatically. You can update the module layer and do all the necessary things to register the component in the IDE. I would also suggest to remove the Custom Component project from the standard distribution. Or can you clarify some more what the user can achieve with the Custom Component project that he cannot achieve with the NB Module project? What is actually simpler to do with the Custom Project for the user?
>In my view the Custom Component project is nothing else than a narrowed NetBeans Module project. It doesn't hide NB >api development, as the user needs to >know the mobility module API at least. Is that correct? At first I actually thought this was going to create some sort >of standardized mobility components >similar to JavaBeans. In fact it's NetBeans specific which isn't obvious and may be misleading. I don't understand what is misleading? Creation of the Mobility Custom Component New Project wizard is placed in the Mobility category so there is no way that users are misinform. Wizard helps user to take all necessary steps to create skeleton of the project at the moment of project creation. Advanced users have also possibility to use some of the API Support feature like Actions or TopComponent so that's why we extending API Support not creating our own project type because it'd be duplication. On the other hand using standard Api Support New Project wizard may be misleading, for example layer.xml is not mandatory and it is mandatory in Mobility Custom Component Support. >Therefor I propose to enhance the NB Module project with the custom component template. If the user creates it, add >all required libraries to the project >automatically. You can update the module layer and do all the necessary things to register the component in the IDE. >I would also suggest to remove the Custom Component project from the standard distribution. It is not in the standard distribiution. It comes with Netbeans Mobility version only. >Or can you clarify some more what the user can achieve with >the Custom Component project that he cannot achieve with the NB Module project? What is actually simpler to do with >the Custom Project for the user? For example we could put predefine layer.xml with folders used in the Mobility Custom Component architecture. Predefine there comments, components, producers or add basic sets of MIDP libraries. So user don't have to figure it out on his own how to do it. Of course all thees things could be achieved only with API Support but we want it do it as simple and helpful as it's possible.
>I don't understand what is misleading? I meant the fact it creates NetBeans components using NetBeans APIs packaged in NetBeans nbm format. Whereas for example in Swing you can create a _standard_ component packaged in a JAR file you can then use in any tools and projects. I tried to say we should say it in the beginning that this is NetBeans specific thing. >It is not in the standard distribiution. It comes with Netbeans Mobility version only. By standard distribution I meant any available IDE download from the netbeans.org website. I talked about this with Petr and we'll get back to talk about it again. My point is that if it's possible to do all the things you mentioned (modify the layer, add libraries) when the user uses the custom component template inside the _Module_ project, then we need to clearly state the reason for the special project type.
Jano, I am finally going over this issue and here are some of my observation. This is not a special kind of project from NetBeans point of view as far as it creates standard nbm. The issue with standard project is, that anyone who wants to start with custom component really wants to be isolated from NetBeans low level API's and terminology at some point. Here are some of my suggestions: - The project entry should be in mobility category, but residing as the last icon - Project should use standard NetBeans project icon - Project should be well described in the project type hint - The first project panel should have a same L&F and content as standard NetBeans module wizard, permitting user to use same options. - The rest of project allows user to create all Mobility Component related content seamlessely, giving the people better customized experience when creating new stuff for Visual Designer. We can also better tune the wizard to have a good user experience. This seems to be as best trade off between usability/confusion. Could you comment on this?
What you described seems the right way to go. The icon, better description and actual consistency with module project may help clear the confusion. I see it as something like the new "NetBeans Platform Application" project which is the same as "Module Suite" project, but we have a special template for it for discoverability and other reasons. Regarding the name, I would suggest to tune it a bit. I think neither "Custom", nor "Project" is necessary. All items in the wizard are custom and projects. Maybe something like: "Palette Components" or "Palette Component Module" or "Mobile Designer Components" or "Mobile Designer Palette Components" or something else. What do you think?
> "NetBeans Platform Application" project which is the same as "Module Suite" project, but we have a special template for > it for > discoverability and other reasons. Yes, this is what I mean. It is still the same project type, but with customized usage, which is important for people understanding. > "Palette Components" or "Palette Component Module" or "Mobile Designer Components" or "Mobile Designer Palette > Components" or something else. "Mobile Designer Components" sound the best for me, the rest does not make much sense to me
Okay, so I'll modify the permanent UI spec like this: --- Mobility MIDP Application Mobile Class Library Mobile Project from Existing MIDP Sources Import Wireless Toolkit Project CDC Application CDC Class Library Import CDC Pack 5.5 Project Import CDC Toolkit Project Mobile Designer Components --- Please speak up if you want some other changes. Reassigning to the module owner to fix the implementation. Thanks!
Reassigning to Andrew
there is one more change n UI. New File Type: http://wiki.netbeans.org/MobilityCustomComponentProjectSupport#section-MobilityCustomComponentProjectSupport-CustomComponent I use the following names. category : "Mobile Designer Components" file type: "Custom Component"
For the File wizard, I would suggest the category name and placement: --- Module Development * Mobile Designer Java * Swing GUI Forms * AWT GUI Forms * JUnit * XML * Other * --- The template name would be "Mobile Designer Component". Do you agree?
Looks good. thank you.
> The project entry should be in mobility category, but residing as the last icon http://hg.netbeans.org/main/rev/5094c634f65c > Project should use standard NetBeans project icon http://hg.netbeans.org/main/rev/9ba297616231 > Project should be well described in the project type hint http://hg.netbeans.org/main/rev/d18f2f9dc430 > change project name to "Mobile Designer Components" http://hg.netbeans.org/main/rev/c946902014aa > change file type name http://hg.netbeans.org/main/rev/8ca8742f1a59 first project creation wizard step Look&Feel implementation is under discussion.
*** Issue 137280 has been marked as a duplicate of this issue. ***
I updated the File Wizard spec: http://wiki.netbeans.org/NewFileWizard The "Mobile Designer" category and "Mobile Designer Component" template were added to the following projects: - Mobile Designer Components - Module - Library Wrapper Module I wasn't sure about the wrapper module template, but it seems this project type just uses the same file categories as the Module project. If it's not like that, please let me know. Thanks!
correct.
I had to add one addition panel "Mobility" to the Netbeans Options(Preferences)/Miscellaneous with one check box and note. You can find details here: http://wiki.netbeans.org/MobilityCustomComponentProjectSupport#section-MobilityCustomComponentProjectSupport-AdditionalInformationAndReferences Please review this additional UI. It's not in the trunk yet (because M1) but it's described in the document listed above including screen shots.
Wrong link i last post, this one is correct. http://wiki.netbeans.org/MobilityCustomComponentProjectSupport#section-MobilityCustomComponentProjectSupport-AdditionalDebuggingProjectViews I'm sorry.
My concern with the Mobility Options is discoverability. Options should be used for changing the way features work. In this case the user is supposed to turn the feature on/off in Options dialog. I would say just a very few users would discover this option. Isn't there some other way how to make the debugging views available to the user (maybe automatically)? Another thing is the wording of the check box. Users refer to debugging views when they talk about "Local Variables", "Watches", etc. To really explain what this feature does, it would probably need longer description or some sort of tutorial. What do you think?
>My concern with the Mobility Options is discoverability. Options should be used for changing the way features work. In >this case the user is supposed to turn >the feature on/off in Options dialog. I would say just a very few users would discover this option. Isn't there some >other way how to make the debugging >views available to the user (maybe automatically)? I think it shouldn't be visible for most of the users. This feature is targeting only Mobility Custom Components developers so as a developer you should be aware if and how to ise it (regular Mobility developers don't need it). Any other solution requires interference with API project support which I'd rather avoid. For example it could be available and integrated into the debugging ant script but as I mentioned I don't want to change anything in the API support. Also this "Mobility" tab in is only visible when Mobility Custom Component Support is installed. >Another thing is the wording of the check box. Users refer to debugging views when they talk about "Local Variables", >"Watches", etc. To really explain what >this feature does, it would probably need longer description or some sort of tutorial. ?What do you think? We definitely will release tutorial how to use Custom Component Support and document this feature as well as whole Mobility Custom Component Support. Also I may add some additioanl information inti the "NOTE" label on the Mobility panel.
fixed http://hg.netbeans.org/main/rev/a547d79cd559