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.
CVS UI specs dictates two project's node customizations: - put selected actions directly into context menu right before Tools submenu <http://ui.netbeans.org/nonav/docs/hi/promoF/vcs-spec.html#Contextual_Menu_Project_Node> - dynamically badge project icon providing up-to-date, out-out-date and unversioned feedback For actions I propose following solution. Introduce recommendation that all project type UI providers should consult well-known SFS folder (e.g. "Projects/GenericContextMenuRegistry") and load action instances from it. I talked to J2SE (tzezula) and J2ME (asotona) project authors and they are willing to accept it. For badging could be used similar approach. Register (new) BadgeProvider intrerface into e.g. "Projects/IconBadgeRegistry". Where BadgeProvider reads: package org.openide.nodes; public interface BadgeProvider { Image badge(Image, Node); add/removeChangeListener(ChangeListener) } Jardo, is not here any instantly available generic solution?
Really ought to be handled by Looks, but we keep on deferring that. :-( I might suggest something like Projects/Popup/ (for consistency with editor) containing instances of Action and/or JSeparator. BadgeProvider's could just go into Lookup.default I guess. The interesting method should perhaps read Image badge(Image icon, Lookup context); where you would check the context for e.g. an instance of Project. Or just pass a Project parameter directly, if the interface is only to be used for this purpose. BTW careful with that UI spec. It does not specify what to do when part of the project - e.g. external ${src.dir} - is under CVS but part - e.g. main project dir incl. nbproject - is not. I guess it should then be treated as unversioned (but e.g. "Source Packages" would have the versioning UI).
Jesse is right. Moreover I am working on generic solution, but its not going to be ready for 4.2 (http://openidex.netbeans.org/proposals/looks/). That is why we need to solve it in different way, which will in future be replaceable with the general solution. I like the folder for actions. That is what we use for loaders and works ok. The name for loaders is Loaders/mime/type/Actions as described at http://www.netbeans.org/download/dev/javadoc/usecases.html#usecase-Loaders I would suggest you to select similary actionContext name. Jesse's badging interface is better than the one using Nodes, but I am affraid that it is too generic. I support the idea to create Project specific badging interface that uses Project as parameter, is registered in meta-inf/services and is used by the project ui module. Hopefully we will be able to replace this one in future by calling it from the general infrastructure.
I like Projects/Popup approach. I update J2SE project node that is crucial for upcoming CVS usability study. Any objections?
Must go through apireviews.
Created attachment 21651 [details] Proposed J2SEPhysicalViewProvider.java patch
Should certainly remove ToolsAction if we're going to all this trouble.
Req1: If we decide to read the actions from layer, then we should read all the actions not just some of them. I read the diff that it composes the menu from some hardcoded actions and adds the layer ones to a well defined place. Better mimic http://openide.netbeans.org/servlets/NewsItemView?newsItemID=522 and read the whole popup (if necessary then filter out the fix broken build action). Req2: Write a simple test for the behaviour. Req3: Document the API in arch*xml documents and maybe some guidelines for project writers.
I think I disagree with Req1. The base context menu is different for every project type. But providers such as VCS need to add items to every project type. Therefore there would need to be two kinds of folders: Projects/generic/Actions/ and e.g. Projects/org-netbeans-modules-java-j2seproject/Actions/, where the project combines actions from the two folders together, with more specific items taking precedence. Possible, but would require some hacking around with MultiFileSystem to make it work right incl. folder ordering attrs. (It has been suggested that Registry have a simple "merge" method to make this kind of thing easier - currently done in a very nasty fashion by the editor to handle type-specific context menus.) Since there is no particular use case currently for declaratively modifying the context menu of a *particular* project type, and doing so later would not be incompatible with the simpler approach of having one folder and just inserting its contents into a fixed action list, I suggest we go the simple way for now.
Contract for actions defined by issue #57874. Lets notify all project type owners to honor it. Known project types: J2SE project Web application Enterprise application EJB module J2ME application Freeform Project Apisupport project (used by nbdevelopers)
Created attachment 22001 [details] J2SE project actions integration example
I am not sure what is the current thinking about badges, but why we just cannot reuse FileSystem.HtmlStatus as any other regular data node does? Let's just modify the PackageNode to call getDisplayName() { return packageFile.getFileSystem().getStatus().annotateDisplayName (origPkgName); } and you will get chance to annotate. Of course this does not work if you wish to have diferent annotation for the same folder in Files/Package views, but I was told by msandor, that this was never a goal.
Will FileSystem.HtmlStatus work for project root nodes, given that a project may have multiple independent source roots, and some may be versioned while others not (for example)?
*** Issue 58572 has been marked as a duplicate of this issue. ***
Project node icon badging > multiple independent source roots It's up to CVS Annotator.annotateIcon. It gets set of files. If at least one folder is versioned then icon badging appears. User can expand the node and follow subnodes badging to get clue. Conclusion project types should adapt created project nodes and annotate icon using: getIcon(int type) { Project p = ... Set files = new ... Sources s = p.getLookup().lookup(Sources.class); SourceGroup groups[] = s.getSourceGroups(...); for ( g: groups) { files.add(g.getRootFolder()); } Image orig = super.getIcon(t); FileSystem.Status ann = <any fs, assert all are the same> return ann.annotateIcon(orig, type, files); }
Example clarification. CVS project actions work over TYPE_GENERIC groups, so be consistent please: - SourceGroup groups[] = s.getSourceGroups(...); + SourceGroup groups[] = s.getSourceGroups(SourceGroup.TYPE_GENERIC);
Package node icons badged. PackageViewChildren.java new revision: 1.59 All project types that use PackageViewChildren SPI inherit this feature.
See Project/folder/file node template addressing icon and display name annotating <http://javacvs.netbeans.org/source/browse/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/ui/Attic/LogicalFileAnnotator.java.template?rev=1.1.2.3&hideattic=1&content-type=text/vnd.viewcvs-markup> I have copy&pasted into J2SE and Web project nodes.
Why is this still open? What exactly is missing?
Closing, see previous comment.