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.
Summary: | Replacement for JInlineMenu | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Actions | Assignee: | Milos Kleint <mkleint> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dstrupl, ibrandt, jchalupa, jrechtacek, mkleint, phrebejk, pjiricka, risto09q894, tboudreau |
Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 9679, 11048, 17463, 32633, 35835, 36454, 37433, 57874 | ||
Attachments: | final diff of the changes to be applied, including documentation. |
Description
Jesse Glick
2003-08-28 14:41:55 UTC
Possibly related: issue #34700 Note that the semantics for the get*Presenters methods needs to be a bit different than the existing get*Presenter methods in Presenter.Menu and .Popup: the presenter method needs to be called each time the menu is to be displayed, not only when it is constructed. For Presenter.Popup, this is not much of an issue, since the popup is always constructed from scratch, anyway. For Presenter.Menu, it means that the parent JMenu needs to be written to rebuild itself whenever it is shown, at least if there is >= 1 action in it with Presenter.VariableMenu. I have found (in javadoc's IndexOverviewAction) that it works well to override JMenu.getPopupMenu for this purpose, as the method is called when and only when the user actually posts the menu. If it is found to be inefficient to call add/remove(JMenuItem) several times and create a new JPopupMenu every time the menu is posted, and it seems that many P.VariableMenu's often have the same contents from posting to posting (so that the effort would usually be wasted), then the simple API would not be right - you have no way of telling when the menu items have changed. You could require the JMenuItem instances to be kept identical unless a change is fired, but this seems unwise, since it requires the action to cache the JMenuItem instances - which is unsafe if the action might be presented in more than one place in parallel. Better IMHO would be to follow the Actions.SubMenuModel style, e.g. (here modifying VariablePopup mainly for API consistency with VariableMenu): interface VariableMenu { Object[] getMenuPresenterKeys(); JMenuItem getMenuPresenter(Object key); } interface VariablePopup { Object[] getPopupPresenterKeys(); JMenuItem getPopupPresenter(Object key, boolean defaultChoice); } Here the idea is that the get*PresenterKeys() methods can be called frequently and cheaply - every time the menu is posted. The keys can be any (non-null) objects, compared using equals(). If a key is removed between posts, that menu item is removed. If a key is added, the get*Presenter method is called to convert it to a JMenuItem to display - which the JMenu can hold on to (i.e. get*Presenter should create a fresh component, not use a cache). If the keys are reordered, the menu items are reordered. The JMenu is free to hold a hard reference to the keys last returned from the get*PresenterKeys() method; if they have not changed (Arrays.equals) then getPopupMenu can just call super, using the cached popup for speed; if they have changed, it can make a small number of add/remove(JMI) calls before continuing. Under the assumption that the keys for a typical variable-presenter action would only change intermittently, this could preserve good performance of the menu. BTW the get*Presenter methods in the existing Presenter.* interfaces are IMHO poorly named - should be create*Presenter to emphasize that the method is expected to create a new instance with every call. If introducing a new interface it might be wise to fix the naming, e.g.: interface VariableMenu { Object[] getMenuPresenterKeys(); JMenuItem createMenuPresenter(Object key); } You could create a P.VariableToolbar interface too, to make it easier to produce a list of JButton's, though it is less important since you can already produce e.g. a JPanel with FlowLayout and several JButton's in it. Not sure if JToolBar cares whether or not the buttons in it are added directly to it or via an encapsulating panel - anyone know? It seems you elaborated it in very detail. I think the Actions.SubMenuModel-style sounds well. So to sum it up, for the sake of "defaultChoice" and better naming... would it be fine replace(deprecate) also current Presenter.Menu, Presenter.Popup and Presenter.Toolbar? The new interfaces in Presenter would be: interface FixedMenu { // replaces Menu JMenuItem createMenuPresenter(); } interface FixedPopup { // replaces Popup JMenuItem createPopupPresenter(boolean defaultChoice); } interface FixedToolbar { // replaces Toolbar Component createToolbarPresenter(); } interface VariableMenu { Object[] getMenuPresenterKeys(); JMenuItem createMenuPresenter(Object key); } interface VariablePopup { Object[] getPopupPresenterKeys(); JMenuItem createPopupPresenter(Object key, boolean defaultChoice); } .. of course it the prefix "Fixed" isn't the proper one could be changed. Bring it up on nbdev, I guess. I don't have a strong feeling either way re. leaving Presenter.Menu as it is vs. deprecating and replacing with a Presenter.FixedMenu. There is a stronger argument for deprecating Popup in favor of a new FixedPopup, since you have a chance to add the new boolean param. Couple of bugs that would not have happened had this been implemented. A (possibly weak) argument against the API change (in Presenter) is that there are quite a lot of classes where Presenter.Menu and Presenter.Popup are used/implemnented out there. So removal of the interfaces is probably not an option here - deprecation is the only way here IMHO. Adding Milos and myself to cc. A couple thoughts, in keeping with the KISS principle. This goes more to issues with the main menu than specifically to JInlineMenu, although that's affected too. What if dynamically self-populating menus are just silly? I'm thinking here also of how to solve the menu problems for the screen menu bar on os-x; the problem there is that all of our fancy menu hacks depend on JMenu.getPopupMenu() being called before the menu is posted, and Aqua's screen menu bar just calls it once, when creating the menu, unless a ContainerEvent on the menu tells it items were added or removed - on Aqua, there's simply *no way* to hook the menu posting event and populate it before it's posted. It would be interesting to try and measure the performance of simply: - Create the menu bar. For each action that wants to be in a menu, create a JMenuItem - Let them enable/disable hide/show themselves as is appropriate - Only if a module is removed and its actions need to be cleaned up does anything try to fiddle with the contents of a menu The up side is it's straightforward, using menus as they were designed to be used and will work everywhere. The downside is there will be some unnecessary work happening with hide/shows & enable/disables of menu items when menus are closed, but this should be pretty trivial. Couple this with allowing an action to provide an array of presenters, rather than encouraging folks to use things like JInlineMenu. For the sometimes a submenu, sometimes not case, simply provide two presenters; when one is visible, the other isn't. Re backward compatibility and JInlineMenu, it might be possible to create some kind of monstrosity that dissects its contents and presents them as residents of the menu the JInlineMenu would have lived in. I'm not sure I'd want to write it, but it's not impossible. In the process it would certainly eliminate any lingering menu responsiveness problems we have. Is there anything I'm missing here? Tim, re. OS/X, does what you said apply only to the primary JMenu's directly contained in the JMenuBar, or to even nested JMenu's? Just wondering. Current use cases we have for the main menu bar that I am aware of: 1. PasteAction shows a menu item (enabled or not) or a submenu depending on how many paste types there are. Probably it could always be a submenu? Or there could be a menu item "Paste" (always runs the default type) and a submenu "Paste Other... >" with alternate choices? 2. ToolsAction shows zero or more actions depending on whether or not they are enabled. We know this is poor UI anyway (the list is constructed with no particular ordering etc.). If there is a strict UI requirement that all available actions be discoverable from the main menu then we may have a clutter problem, I am not sure. Anyway, consider removing Tools/ToolsAction and directly registering menu items that are really relevant to the user. 3. Various menu items show dynamically populated submenus, e.g. View -> Toolbars, View -> Documentation Indices, upcoming File -> Recent Projects, etc. etc. Hopefully these do not cause a problem for OS/X. 4. Currently in the build system we have some menu items that change their text depending on the selection. 5. Some stuff in the Versioning menu is probably dynamic (I don't know what). >Tim, re. OS/X, does what you said apply only to the primary JMenu's >directly contained in the JMenuBar, or to even nested JMenu's? Didn't check that yet. >Currently in the build system we have some menu items that change >their text depending on the selection. Dynamically changing menu items work fine (as well as setVisible(), etc.), as long as the menu item fires the appropriate property change it's supposed to when it changes. So the Tools menu could be still be "dynamic", just by irrelevant menu items becoming invisible when they become irrelevant and visible when they become relevant - seems a more straightforward way to handle that anyway. > If there is a strict UI requirement that all available actions be discoverable from the main > menu then we may have a clutter problem, I am not sure. We already do have that problem - some EE users with Refactorit already have a problem with the Tools menu extending offscreen (AFAIK, Swing menus offer no built in support for handling this well, although most desktop gui toolkits do). > 3. Various menu items show dynamically populated submenus, e.g. View > -> Toolbars, View -> Documentation Indices, upcoming File -> Recent > Projects, etc. etc. Hopefully these do not cause a problem for OS/X These seem to work fine (although I note with amusement that if you create a new toolbar configuration with the IDE showing file extensions, your toolbar name contains ".xml"...sigh) A few notes about the usecases how the JInlineMenu is used. 1. the most common pattern is similar to what it in org.netbeans.modules.xml.core.actions.CollectSystemAction. Menu listens all the time on changed activated nodes using a weak listener and on the menuitems it contains for property changes (Enabled/disabled). 2. ToolsAction changes dynamically when displayed, expecting changes in number of items on the menu. Not sure how valid is this usecase. JInline menu is used in popup to either show submenu or hide completely. both 1+2 expect semantics of the addnotify and removenotify in jinlinemenu. I believe the listening on the menuitems in 1 is not necessary if the items are action-based(?) 3. Filesystem action is used for tunneling filesystem actions through the datasystem layer. it uses the same pattern as 1. Any way to get rid of it? 4. The most scary example of JInlineMenu usage is the combo VcsCommandsAction-FileSystemAction-VcsFSCommandsAction in the Versioning menu, it contains 3 nested JInlineMenus. The first two both listen on changes in activated nodes. I"ve tried to implement something along the lines described in the enhancement, however I failed, because of the described usecases. Quite a problem is keeping track of the nested growing/shrinking menus (ad 4). also the listening based on addnotify/removenotify is about to cause problems. Not sure if/how the usecases can be dropped. I think I could not find only a single usecase which would require a static multivalue popup or menu (ExtraWebAction in web module). If JInlineMenu was required, it always came with dynamic changes at runtime, or even while the item is displayed. I believe the removal/replacing of JInlineMenu is not possible with the current usecases and without a clear simplification of what is expected and how dynamic the menu should be. the most common pattern (listening on changed activated nodes) can be probably removed once looks API is in place and modules can register arbitrary action for dataobjects/mimetypes or fileobjects. Looks API can also make FileSystemAction obsolete, since the vcs module can register it's look (#21365) on the layer. Fact is that vcs doesn't rely on Action to backup it's menuitems. Since it's completely dynamic, it cannot use singleton SystemAction, however with introduction of context aware action, this objection is obsolete I believe. Not implemented yet on the vcs side yet though. The use case in Tools menu should be removed and not considered for the rewrite (dynamic changes while the menu is visible). I don't have data available on how frequent it is, however I believe it can be ignored, as long as the menu/popup updates correctly when reinvoked. Although I don't fully understand your use cases here goes a general observation: when the user can see either popup or menu it is kind of unexpected (stupid) user experience for the menu to change (just imagine it - you are browsing a menu and it will change under your hands). If the menu is not displayed there is no need to do any dynamic change. I know this is kind of simple argument but I beleive it is valid. All other discussion is about some legacy code that have been using it. But all of this code is IMHO poorly written. Agree. I wanted to point out that the current usage of JInlineMenu can
be either removed or rewritten to use other means than dynamically
changing the menu.
>If the menu is not displayed there is no need to do any
>dynamic change.
Not completely sure, taking the Mac OSX into account.
Tim, if we display all available actions (eg coming from Tools..) in
the menu and everytime addNotify() is called on the parent, can we
check the contained MenuItems for Action and it's state? and maybe
hide/show based on that? Will that be any different from the current
approach of adding/removing? or Is that supposed to happen right when
the action changes state even when the menu is not visible?
Assigned to new owner. The issue prevents to write correct code for dynamically evaluated menu contents. Currently used JInlineMenu is deprecated *without* known rewrite. Proposed interfaces are considered to be suggested solution (and should be mentioned in deprecation text). Reclassifing to DEFECT. Milos is working on it. I've added a new interface to Presenter that handles the dynamic aspects of the menu/popup menu. Inspired by tim's menu model work. Not sure the presenter interface is the best place but it definitely needs to be part of Openide' Utilities module. /** * aspect of a Presenter.Menu or Presenter.Popup. if the presenters return * an instance of Presenter.UpdatingMultipleMenu, then the framework code * will use it's methods to populate the menu and keep it uptodate. */ public interface UpdatingMultipleMenu extends Presenter { public JComponent[] getMenuPresenters(); public JComponent[] synchMenuPresenters(JComponent[] items); } It allowed me to keep JInlineMenu more or less backward compatible. Things that are not working now: dynamic update of jinline menu when it's visible (impossible to do for macosx) and nesting of multiple jinlinemenus within each other. done on branch APPLE_MENU_39449. comments welcome. I believe that the interfaces should not be Presenter inner class, but it should be somewhere in org.openide.awt. The interfaces in Presenter are to be directly implemented by Action, this one is not, please move it to the awt package. The javadoc is not the greatest. I do not understand what the two methods are for. This is maybe also due to the fact that you have no tests that I could find. Please write some tests to show how this is supposed to be used. Please test Utilities.actionsToPopup and loader's MenuFolder (or DynaMenuModel). Beyond that I am glad you managed to get this long standing issue working. tests added, javadoc improved. class moved out of presenter interface and renamed to DynamicMenuContent. It's still in org.openide.util. I'm not a supporter of moving to openide.awt because its usage is tightly coupled with the Presenter class and thus should be close to it. (I still need to write apichanges entry and mention the DynamicMenuContent interface in Presenter.) Maybe I missed something here, but wasn't the point to deprecate - i.e. ultimately remove - JInlineMenu? If so, why do you care about keeping backward compatibility for it? IMHO we should just remove all usages of JInlineMenu from any NB code; provide a new interface that uses no scary Swing tricks, works 100% on Macs, and solves our real use cases (after deleting any bad idioms we don't want or need to keep, e.g. updating menus while they are visible, or inserting children other than JMenuItem's and nested JMenu's into a JMenu); and use the new interface for all code which wants to have dynamically adjusted menu items. I would be -0 on this change until there is some explanation of what it is supposed to achieve, in terms of specific use cases. Well, the fundamental non-intuitive thing with our entire actions API is the notion of an "action" which actually doesn't represent an action, it represents a menu, or multiple actions, etc. It's understandable in an organic "actions == thingies that can appear in menus == random components" kind of way, but in fact it's pretty bizarre that we call such things "actions". But we're not going to fix that without a redesign of the whole way actions are registered. Agree that nobody anywhere should be using JInlineMenu in our codebase. +1 on Milos' patches if it can make the screen menu bar usable though. This can't have been fun stuff to code. well, I *can* remove JInlineMenu in a minute. But.. the current JInlineMenu implementation is more or less a noop. It has a setter for the menuitems but doens't really do anything. it also implements the new interface and when the infrastucture calls the interface methods the saved menuitems are returned. Absolutely no funky code there. So it's backward compatible, it's not harmful and allows me to commit the changes and file bugs against individual modules using old JinlineMenu. BTW I've rewritten ToolsAction to avoid JInlineMenu. Created attachment 23083 [details]
final diff of the changes to be applied, including documentation.
as per yarda's request, I've moved the new DynamicMenuContent interface from openide/util to openide/awt. also moved the testcase for it and updated javadoc. I plan to integrate by tomorrow. When stating version numbers in Javadoc, always use "code.name.base major.minor" syntax, since we have split openide. E.g. "org.openide.awt 6.5". The patch to openide/util/test/unit/src/org/openide/util/UtilitiesActionsTest.java can presumably be reverted. The diff doesn't seem to contain the actual added DynamicMenuContent.java...? updated javadoc. fixed in trunk. will be part of 20050714 daily build. Jesse: how do I get cvs diff to include diffs on new, added files? Checking in openide/actions/manifest.mf; /cvs/openide/actions/manifest.mf,v <-- manifest.mf new revision: 1.4; previous revision: 1.3 done Checking in openide/actions/nbproject/project.xml; /cvs/openide/actions/nbproject/project.xml,v <-- project.xml new revision: 1.5; previous revision: 1.4 done Checking in openide/actions/src/org/openide/actions/NewAction.java; /cvs/openide/actions/src/org/openide/actions/NewAction.java,v <-- NewAction.java new revision: 1.2; previous revision: 1.1 done Checking in openide/actions/src/org/openide/actions/ToolsAction.java; /cvs/openide/actions/src/org/openide/actions/ToolsAction.java,v <-- ToolsAction.java new revision: 1.2; previous revision: 1.1 done Checking in openide/arch/arch-openide-actions.xml; /cvs/openide/arch/arch-openide-actions.xml,v <-- arch-openide-actions.xml new revision: 1.31; previous revision: 1.30 done Checking in openide/awt/apichanges.xml; /cvs/openide/awt/apichanges.xml,v <-- apichanges.xml new revision: 1.6; previous revision: 1.5 done Checking in openide/awt/manifest.mf; /cvs/openide/awt/manifest.mf,v <-- manifest.mf new revision: 1.6; previous revision: 1.5 done Checking in openide/awt/nbproject/project.properties; /cvs/openide/awt/nbproject/project.properties,v <-- project.properties new revision: 1.4; previous revision: 1.3 done Checking in openide/awt/nbproject/project.xml; /cvs/openide/awt/nbproject/project.xml,v <-- project.xml new revision: 1.5; previous revision: 1.4 done Checking in openide/awt/src/org/netbeans/modules/openide/awt/DefaultAWTBridge.java; /cvs/openide/awt/src/org/netbeans/modules/openide/awt/DefaultAWTBridge.java,v <-- DefaultAWTBridge.java new revision: 1.3; previous revision: 1.2 done Checking in openide/awt/src/org/openide/awt/Actions.java; /cvs/openide/awt/src/org/openide/awt/Actions.java,v <-- Actions.java new revision: 1.3; previous revision: 1.2 done RCS file: /cvs/openide/awt/src/org/openide/awt/DynamicMenuContent.java,v done Checking in openide/awt/src/org/openide/awt/DynamicMenuContent.java; /cvs/openide/awt/src/org/openide/awt/DynamicMenuContent.java,v <-- DynamicMenuContent.java initial revision: 1.1 done Checking in openide/awt/src/org/openide/awt/JInlineMenu.java; /cvs/openide/awt/src/org/openide/awt/JInlineMenu.java,v <-- JInlineMenu.java new revision: 1.2; previous revision: 1.1 done Checking in openide/awt/src/org/openide/awt/JMenuPlus.java; /cvs/openide/awt/src/org/openide/awt/JMenuPlus.java,v <-- JMenuPlus.java new revision: 1.2; previous revision: 1.1 done Checking in openide/awt/src/org/openide/awt/JPopupMenuPlus.java; /cvs/openide/awt/src/org/openide/awt/JPopupMenuPlus.java,v <-- JPopupMenuPlus.java new revision: 1.2; previous revision: 1.1 done Checking in openide/awt/src/org/openide/awt/JPopupMenuUtils.java; /cvs/openide/awt/src/org/openide/awt/JPopupMenuUtils.java,v <-- JPopupMenuUtils.java new revision: 1.2; previous revision: 1.1 done RCS file: /cvs/openide/awt/test/build-unit.xml,v done Checking in openide/awt/test/build-unit.xml; /cvs/openide/awt/test/build-unit.xml,v <-- build-unit.xml initial revision: 1.1 done RCS file: /cvs/openide/awt/test/build.xml,v done Checking in openide/awt/test/build.xml; /cvs/openide/awt/test/build.xml,v <-- build.xml initial revision: 1.1 done RCS file: /cvs/openide/awt/test/cfg-unit.xml,v done Checking in openide/awt/test/cfg-unit.xml; /cvs/openide/awt/test/cfg-unit.xml,v <-- cfg-unit.xml initial revision: 1.1 done RCS file: /cvs/openide/awt/test/unit/src/org/openide/awt/UtilitiesActionsTest.java,v done Checking in openide/awt/test/unit/src/org/openide/awt/UtilitiesActionsTest.java; /cvs/openide/awt/test/unit/src/org/openide/awt/UtilitiesActionsTest.java,v <-- UtilitiesActionsTest.java initial revision: 1.1 done Checking in openide/loaders/manifest.mf; /cvs/openide/loaders/manifest.mf,v <-- manifest.mf new revision: 1.22; previous revision: 1.21 done Checking in openide/loaders/nbproject/project.xml; /cvs/openide/loaders/nbproject/project.xml,v <-- project.xml new revision: 1.10; previous revision: 1.9 done Checking in openide/loaders/src/org/openide/awt/DynaMenuModel.java; /cvs/openide/loaders/src/org/openide/awt/DynaMenuModel.java,v <-- DynaMenuModel.java new revision: 1.2; previous revision: 1.1 done Checking in openide/loaders/src/org/openide/awt/MenuBar.java; /cvs/openide/loaders/src/org/openide/awt/MenuBar.java,v <-- MenuBar.java new revision: 1.13; previous revision: 1.12 done Checking in openide/loaders/test/unit/src/org/openide/awt/DynaMenuModelTest.java; /cvs/openide/loaders/test/unit/src/org/openide/awt/DynaMenuModelTest.java,v <-- DynaMenuModelTest.java new revision: 1.2; previous revision: 1.1 done Checking in openide/util/apichanges.xml; /cvs/openide/util/apichanges.xml,v <-- apichanges.xml new revision: 1.8; previous revision: 1.7 done Checking in openide/util/manifest.mf; /cvs/openide/util/manifest.mf,v <-- manifest.mf new revision: 1.5; previous revision: 1.4 done Checking in openide/util/src/org/netbeans/modules/openide/util/AWTBridge.java; /cvs/openide/util/src/org/netbeans/modules/openide/util/AWTBridge.java,v <-- AWTBridge.java new revision: 1.2; previous revision: 1.1 done Checking in openide/util/src/org/openide/util/Utilities.java; /cvs/openide/util/src/org/openide/util/Utilities.java,v <-- Utilities.java new revision: 1.3; previous revision: 1.2 done Checking in openide/util/src/org/openide/util/actions/Presenter.java; /cvs/openide/util/src/org/openide/util/actions/Presenter.java,v <-- Presenter.java new revision: 1.2; previous revision: 1.1 done Checking in openide/www/proposals/actions/index.html; /cvs/openide/www/proposals/actions/index.html,v <-- index.html new revision: 1.23; previous revision: 1.22 done Checking in editor/nbproject/project.properties; /cvs/editor/nbproject/project.properties,v <-- project.properties new revision: 1.15; previous revision: 1.14 done Checking in editor/nbproject/project.xml; /cvs/editor/nbproject/project.xml,v <-- project.xml new revision: 1.19; previous revision: 1.18 done Checking in editor/src/org/netbeans/modules/editor/NbCodeFoldingAction.java; /cvs/editor/src/org/netbeans/modules/editor/NbCodeFoldingAction.java,v <-- NbCodeFoldingAction.java new revision: 1.12; previous revision: 1.11 done Checking in editor/src/org/netbeans/modules/editor/NbEditorKit.java; /cvs/editor/src/org/netbeans/modules/editor/NbEditorKit.java,v <-- NbEditorKit.java new revision: 1.85; previous revision: 1.84 done Checking in junit/manifest.mf; /cvs/junit/manifest.mf,v <-- manifest.mf new revision: 1.39; previous revision: 1.38 done Checking in junit/nbproject/project.xml; /cvs/junit/nbproject/project.xml,v <-- project.xml new revision: 1.7; previous revision: 1.6 done Checking in junit/src/org/netbeans/modules/junit/TestsAction.java; /cvs/junit/src/org/netbeans/modules/junit/TestsAction.java,v <-- TestsAction.java new revision: 1.11; previous revision: 1.10 done Checking in javadoc/manifest.mf; /cvs/javadoc/manifest.mf,v <-- manifest.mf new revision: 1.69; previous revision: 1.68 done Checking in javadoc/nbproject/project.xml; /cvs/javadoc/nbproject/project.xml,v <-- project.xml new revision: 1.9; previous revision: 1.8 done Checking in javadoc/src/org/netbeans/modules/javadoc/search/IndexOverviewAction.java; /cvs/javadoc/src/org/netbeans/modules/javadoc/search/IndexOverviewAction.java,v <-- IndexOverviewAction.java new revision: 1.15; previous revision: 1.14 done Checking in i18n/src/org/netbeans/modules/i18n/I18nGroupAction.java; /cvs/i18n/src/org/netbeans/modules/i18n/I18nGroupAction.java,v <-- I18nGroupAction.java new revision: 1.14; previous revision: 1.13 done Checking in ide/applemenu/src/org/netbeans/modules/applemenu/layer.xml; /cvs/ide/applemenu/src/org/netbeans/modules/applemenu/layer.xml,v <-- layer.xml new revision: 1.8; previous revision: 1.7 done Checking in ide/launcher/netbeans.conf; /cvs/ide/launcher/netbeans.conf,v <-- netbeans.conf new revision: 1.17; previous revision: 1.16 done Checking in ide/launcher/unix/netbeans; /cvs/ide/launcher/unix/netbeans,v <-- netbeans new revision: 1.19; previous revision: 1.18 done Checking in projects/projectui/nbproject/project.properties; /cvs/projects/projectui/nbproject/project.properties,v <-- project.properties new revision: 1.7; previous revision: 1.6 done Checking in projects/projectui/nbproject/project.xml; /cvs/projects/projectui/nbproject/project.xml,v <-- project.xml new revision: 1.19; previous revision: 1.18 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/actions/RecentProjects.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/actions/RecentProjects.java,v <-- RecentProjects.java new revision: 1.12; previous revision: 1.11 done cvs diff -u -N This issue had *1 votes* before move to platform component |