Bugzilla – Full Text Bug Listing
| Summary: | [ds tooling] New Component wizard should create OSGI-INF folder and always place component definitions in that folder | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Philipp Kursawe <phil.kursawe> | ||||||||||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | caniszczyk, lars, rafael.oliveira, sja.eclipse | ||||||||||||
| Version: | 3.5 | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | stalebug | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Philipp Kursawe
This really is a more specific duplicate of bug 254969, which talks about supporting folder creation and encouraging the use of OSGI-INF. The DS spec does not require the component XML documents to live in a particular place, so it seems that forcing people to use OSGI-INF is not ideal. I would rather let people choose, but encourage them to use OSGI-INF nevertheless. Rather than marking this as a duplicate myself, I'm going to leave it to Chris or Rafael to decide. Also see bug 252913, "ensure component xml files are included in bin.includes". I know its not in the DS specs, but the OSGi specs define OSGI-INF/l10n/ as the base folder for l10n. So it makes sense to pack all OSGi related things under OSGI-INF, although one can question the introduction of another "INF" folder by the OSGi people beside META-INF altogether. However I agree with you that it should be an encouragement for users to use OSGI-INF. I think one strategy we could employ is that the wizard can check for that folder, and if it's there, offer it as the default. If the folder doesn't exist, we simply present the user with what is available. I think that sounds like a fair approach. And also offer to create the folder if it does not exist. Like when the user enters OSGI-INF/ComponentName as the name of the component. Re- comment 3: Yes Philipp, I agree that using OSGI-INF makes sense, and for the bundles I build I always use it. Unfortuante we've seen people complain before when PDE forces things to be in particular places (plugin.xml at the root of the bundle, for example). Regarding using META-INF, I hear that this folder is sometimes NOT signed, which I am told can cause problems, although I've never seen this myself. Re- comment 4: Sounds good Chris, so long as you don't plan to prompt the user with a dialog everytime. ;-) Re- comment 5: I was talking recently with Rafael about supporting paths in the "File name" field, and one of the issues was possible confusion between the projects tree composite (above the "File name" field) and the contents on the "File name" field. Frankly I'm not a fan of the projects tree composite and would rather see a "Project" field and a "Browse..." button (just like JDT does), but the projects tree composite is already used all over the place in PDE. Finally, it would be helpful if the wizard remembered the user's decision. This is how other PDE wizards work. You can store this either in the preference store on dialog settings. Created attachment 119534 [details]
Prototype
Here is the prototype I got..
1) We ask to the user if he wants to use OSGI-INF as a default folder for component.xml
2) If he said yes and the folder exists, we put it in the StructureSelection and the DSFileWizardPage do the rest
3)If the folder doesn't exists we ask if he wants to create the folder (if yes, we create and put in the StructureSelection and the DSFileWizardPage do the rest).
ps1: I think we should save these options somewhere. (I put the default folder option in the dialog settings).
ps2: I was looking for those MessageDialogs with that checkbox to save the selected option. (Simon said he has one for me!)
ps3: I guess we will need a preference page to let the user undo the saved option, right?
ps4: All messages should be changed, as I'm not a very good writer (even in portuguese) :)
That's it, feedbacks?
Created attachment 119535 [details]
Prototype2
Now with HandyPromptDialog suggested by Simon. (much better!) :)
Cheers,
Created attachment 119573 [details]
Prototype2
Corrected some minor issues.. :)
People, I sent the wrong patch, sorry.. I will sent the right one in few minutes. Created attachment 119574 [details]
Prototype2
Now I think we have the right patch! :)
Rafael: I have tried out the patch, and while it's getting very close, there are still some issues that need addressing: 1) I do NOT like the double dialog box prompt. These two dialogs looks sufficiently similar that it's difficult to understand quite what's going on. In fact, at first, I thought it was a bug and the same dialog was being displayed twice, that is, until I read the dialog text more carefully. You need to remember that developers are notoriously BAD at reading the text in dialogs, which is one of the reasons why the style of naming buttons something other than "Yes" and "No" is sometimes popular (although at this stage I'm not suggesting this). What I am suggesting is that you remove the "Make OSGI-INF as default folder?" dialog. I think I'd rather see this flow: a. If the "Remember my decision" setting is "Yes" for "Do you want to create the OSGI-INF folder?": - Check for the existence of the OSGI-INF folder - If the folder does not exist, create it. b. If the OSGI-INF folder DOES exist the wizard should simply always make it the current selection, and should NOT prompt the user for a default selection. Doing it this way will: - Keep things simple. - Reduce the number of dialog prompts. - Encourage people to use the OSGI-INF folder. - Not force anyone into anything they don't want to do. Remember, once the wizard opens the user can change the selection to something else, so let's not try quite so hard to force them to use OSGI-INF. 2) I think the prompting dialog should have a Cancel button that when clicked terminates the entire operation. While having just "Yes" and "No" works, it's not what the user will expect. (And by the way, if you really do not want the "Cancel" button to appear, the right thing to do is to call setCancelButtonText(null), rather than commenting out the line createCancelButtonForButtonBar(parent) in th HandyPromptDialog class' createButtonsForButtonBar(Composite) method!) 3) While testing the patch, I could not get the "Remember my decision" checkbox to work! It's almost as if the dialog settings are either not getting stored correctly, or the persisted value is not getting acted upon correctly. Either way, something is going wrong there, rendering the checkbox useless. 4) As you mentioned, the wording needs some work. In particular, the correct spelling is "recommended". But I'm sure that Chris will do some word-smithing before he commits anything. Once you provide another patch I will be happy to take another look. Thanks for all your help with this. People, 1,3 and 4 are OK! But I'm facing a code/design problem in Nr.2! (Cancel Button) If the user selects cancel. I don't know how to close the wizard automatically. :) I tried two options: 1-if(canceled) this.getShell().close() - I got a NPE 2-if(canceled) don't create the wizardPage and don't add it. (if I do this, and the user selects DS Wizard again, it won't prompt the questions or open the wizard) I asked in the #eclipse and I received some feebacks from rcjsuen which asked if we shouldn't put this prompt as a WizardPage. (so the user would cancel it in the default cancel button). What do you think? 1-Should I put the "create a new osgi folder?" question as a wizard page? 2-Should I just remove the cancel button? :) 3-Does anyone knows how can I close that wizardDialog that shows all Wizards? :) 4-Any better idea? Rafael, please don't get hung up on point 2, so maybe we should just ignore the Cancel button for now. Let's just get this one resolved for M4 and then we can look again in M5. Created attachment 120039 [details]
Patch
Now, our prototype became a patch! :)
Simon, can you look at this one? Thanks..
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. Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release. |