Community
Participate
Working Groups
Today, exporting package that are "x-internal" is done by: 1. Opening the Manifest Editor. 2. Turning to the Runtime page. 3. Adding the packages to the Exported Packages list. 4. Selecting the exported packages. 5. Selecting the "hidden from plug-ins except:" radio button. 6. Adding NOTHING to the list of plug-ins! It's step 6 that's the gotcha. This is so unexpected that I would imagine that most people don't even know about this capability. Don't get me wrong, I'm certainly not trying to encourage people to use x-friends, but I would like the UI to be more intuitive. ;-) I'm not sure how to label the proposed radio button, but here are some suggestions: - visible as internal to downstream plug-ins - internally visible to downstream plug-ins - visible internally to downstream plug-ins The wording is tricky since you want to communicate the fact that while the package is exported and will be visible, it is still considered internal (ie, not API). A candidate for bugday, perhaps?
adding as a bugday candidate and adding a mylyn context
Created attachment 85878 [details] mylyn/context/zip
I'll take this one. I have a different suggestion for fixing this up. If we just add this radio button, we'll have two radio buttons that really do the exact same thing (the only difference being that one has the associated list). Maybe we should consider simply renaming the 'hidden' radio button to something similar to Simon's suggestions; the functionality isn't changing, but the description can indicate that the exported package is visible as internal. Then we can add a new label above the friends list that can tell the user that the packages selected are completely visible to the plug-ins in the list. I think that could help clarify things, and still accomplish the original goal (help a user understand how to make their packages internal).
...unless I misread the bug description and Simon meant "relabel the radio button", not "add a new radio button", in which case I agree wholeheartedly. :-)
omg NOAM is back ;)
Yep! Can't wait to take a crack at this one. :D
Noam, as the owner of this enhancement I would encourage you to implement it as you see fit. My suggestions are exactly that... suggestions! Maybe when you have something looking the way you want it, attach a few screen shots that show the direction you're headed, I'll be certain to provide feedback. Thanks for taking this one.
Noam, feel free to do as you wish. I'm for a rename + new label for added clarity as it's a bit confusing now.
Created attachment 91108 [details] New Package Visibility section labelling This screenshot has my most recent changes. I changed the labels a bit and added a couple of new ones. Note that the original description of the visibility section said "When the runtime is in strict mode...", so the use of the word "hidden" made perfect sense in that context... but it definitely wasn't telling the user enough about internal package visibility. I tried to put more detail into the descriptions. It seems clearer to me, but I could be a bit biased. :P I would definitely welcome some input at this point since getting the wording right for this will be fairly tricky. Simon, please take a look at this when you can, and let me know what you think. :)
Looks much better. Does Simon approve :)?
Actually, now that I'm looking again... does this violate UI/Geneva conventions, vis a vis the label right after the section description? Or is this alright? :)
you're right. Let's wait for Simon's comments.
OK, first some minor typographical/wordsmith issues... In the first paragraph, the phrase: "...packages will be hidden to downstream plug-ins." should be: "...packages will be hidden from downstream plug-ins." I also have concerns about the radio button labels. o always visible to downstream plug-ins o visible as internal to downstream plug-ins should be: o Visible to downstream plug-ins o Visible as internal to downstream plug-ins The word "always" seems to be at conflict with the first paragraph that talks about strict mode. By convention, the first letter of the first word of the label should be capitalized. But I'm more concerned about how users (especially existing users) will interpret the editor changes. For something to be easy to understand it should not be necessary for the user to do mental acrobatics... for example, what does a user need to do to: - Export one or more packages? - Export one or more package as x-internal? - Export one or more package as an x-friend of one or more bundles? There's a chance that the user does not think in terms of x-internal and x-friend, but whether they do or not, it should be immediately obvious the UI choice they have to make. The original motivation for this bug report what to narrow the mental divide between what the user "thinks" and what the user "does" to achive their goal. My worry is that we've either shifted or widened the mental divide. Maybe some screenshots that show the 3 scenarios above would help me. Thanks
This bug should be easy to take care of (and is a great bugday candidate) but unfortunately I will not be able to make this change any time soon. Sorry everyone, especially Simon, for letting this bug sit and collect dust for so long. I think it's an improvement worth looking into, so I am assigning back to inbox, so a more active contributor can take a look.
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.
