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.

Bug 57776 - Integrate CVS with Project (menus and icons)
Summary: Integrate CVS with Project (menus and icons)
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Milan Kubec
Keywords: API
: 58572 (view as bug list)
Depends on: 58486 57874 57903 58624 58625 58626 58627 58628 58629 58949 59303
Blocks: 54150
  Show dependency tree
Reported: 2005-04-12 15:21 UTC by _ pkuzel
Modified: 2008-10-13 15:20 UTC (History)
4 users (show)

See Also:
Exception Reporter:

Proposed patch (7.01 KB, patch)
2005-04-14 13:55 UTC, _ pkuzel
Details | Diff
J2SE project actions integration example (7.01 KB, patch)
2005-05-05 14:45 UTC, _ pkuzel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2005-04-12 15:21:23 UTC
CVS UI specs dictates two project's node customizations:

  - put selected actions directly into context menu right before Tools submenu

  - 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);

Jardo, is not here any instantly available generic solution?
Comment 1 Jesse Glick 2005-04-12 18:09:03 UTC
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).
Comment 2 Jaroslav Tulach 2005-04-13 09:53:46 UTC
Jesse is right. Moreover I am working on generic solution, but its not going to
be ready for 4.2 (

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
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.

Comment 3 _ pkuzel 2005-04-13 17:11:36 UTC
I like Projects/Popup approach. I update J2SE project node that is crucial for
upcoming CVS usability study. 

Any objections?
Comment 4 Jesse Glick 2005-04-13 17:50:23 UTC
Must go through apireviews.
Comment 5 _ pkuzel 2005-04-14 13:55:55 UTC
Created attachment 21651 [details]
Proposed patch
Comment 6 Jesse Glick 2005-04-14 16:07:30 UTC
Should certainly remove ToolsAction if we're going to all this trouble.
Comment 7 Jaroslav Tulach 2005-04-15 10:37:05 UTC
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 and 
read the whole popup (if necessary then filter out the fix broken build 
Req2: Write a simple test for the behaviour. 
Req3: Document the API in arch*xml documents and maybe some guidelines for 
project writers. 
Comment 8 Jesse Glick 2005-04-15 19:38:39 UTC
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.
Comment 9 _ pkuzel 2005-05-05 13:31:37 UTC
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)
Comment 10 _ pkuzel 2005-05-05 14:45:27 UTC
Created attachment 22001 [details]
J2SE project actions integration example
Comment 11 Jaroslav Tulach 2005-05-06 09:58:22 UTC
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. 
Comment 12 Jesse Glick 2005-05-06 19:06:48 UTC
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)?
Comment 13 _ pkuzel 2005-05-12 13:59:13 UTC
*** Issue 58572 has been marked as a duplicate of this issue. ***
Comment 14 _ pkuzel 2005-05-16 12:49:22 UTC
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) {
   Image orig = super.getIcon(t);
   FileSystem.Status ann = <any fs, assert all are the same>
   return ann.annotateIcon(orig, type, files);
Comment 15 _ pkuzel 2005-05-19 15:16:57 UTC
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);
Comment 16 _ pkuzel 2005-05-23 08:38:11 UTC
Package node icons badged. new revision: 1.59

All project types that use PackageViewChildren SPI inherit this feature.
Comment 17 _ pkuzel 2005-05-31 14:28:17 UTC
See Project/folder/file node template addressing icon and display name annotating

I have copy&pasted into J2SE and Web project nodes.
Comment 18 Jesse Glick 2008-08-20 17:03:43 UTC
Why is this still open? What exactly is missing?
Comment 19 Milan Kubec 2008-10-13 15:20:37 UTC
Closing, see previous comment.