Bug 35827 - Replacement for JInlineMenu
Replacement for JInlineMenu
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Actions
3.x
All All
: P2 (vote)
: 5.x
Assigned To: Milos Kleint
issues@platform
: API, API_REVIEW_FAST
Depends on:
Blocks: 9679 11048 17463 32633 35835 36454 37433 57874
  Show dependency treegraph
 
Reported: 2003-08-28 14:41 UTC by Jesse Glick
Modified: 2008-12-23 14:26 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
final diff of the changes to be applied, including documentation. (113.11 KB, patch)
2005-07-13 14:16 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-08-28 14:41:55 UTC
JInlineMenu is deprecated, and for good reason -
it is evil. We need a replacement that will let
actions produce zero or more menu items (or
submenus) within their container menu, without
resorting to weird Swing tricks.

Suggest perhaps in Presenter:

interface VariableMenu {
    JMenuItem[] getMenuPresenters();
}
interface VariablePopup {
    JMenuItem[] getPopupPresenters(boolean
defaultChoice);
}

(See issue #9679 for the defaultChoice param.)
Comment 1 Jesse Glick 2003-08-28 21:00:52 UTC
Possibly related: issue #34700
Comment 2 Jesse Glick 2003-08-29 15:19:44 UTC
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?
Comment 3 Peter Zavadsky 2003-08-29 16:06:34 UTC
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.
Comment 4 Jesse Glick 2003-08-29 16:13:34 UTC
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.
Comment 5 Jesse Glick 2003-10-03 16:53:02 UTC
Couple of bugs that would not have happened had this been implemented.
Comment 6 David Strupl 2004-01-04 21:44:08 UTC
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.
Comment 7 _ tboudreau 2004-03-12 15:12:43 UTC
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?
Comment 8 Jesse Glick 2004-03-12 16:09:20 UTC
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).
Comment 9 _ tboudreau 2004-03-12 16:57:07 UTC
>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)
Comment 10 Milos Kleint 2004-03-17 15:22:17 UTC
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.
Comment 11 Milos Kleint 2004-03-18 09:31:40 UTC
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.


Comment 12 David Strupl 2004-03-18 09:43:37 UTC
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.
Comment 13 Milos Kleint 2004-03-18 09:58:44 UTC
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?


Comment 14 Jiri Rechtacek 2004-04-23 10:49:24 UTC
Assigned to new owner.
Comment 15 _ pkuzel 2005-04-18 10:41:31 UTC
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. 
Comment 16 Jiri Rechtacek 2005-05-23 09:50:49 UTC
Milos is working on it.
Comment 17 Milos Kleint 2005-06-30 10:50:58 UTC
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.
Comment 18 Jaroslav Tulach 2005-06-30 22:13:50 UTC
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. 
Comment 19 Milos Kleint 2005-07-04 12:58:56 UTC
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.)
Comment 20 Jesse Glick 2005-07-12 04:10:06 UTC
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.
Comment 21 _ tboudreau 2005-07-12 06:39:19 UTC
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.
Comment 22 Milos Kleint 2005-07-12 07:22:49 UTC
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.
Comment 23 Milos Kleint 2005-07-13 14:16:12 UTC
Created attachment 23083 [details]
final diff of the changes to be applied, including documentation.
Comment 24 Milos Kleint 2005-07-13 14:30:08 UTC
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.
Comment 25 Jesse Glick 2005-07-13 20:40:51 UTC
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...?
Comment 26 Milos Kleint 2005-07-14 08:48:24 UTC
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
Comment 27 _ tboudreau 2005-07-14 16:48:41 UTC
cvs diff -u -N
Comment 28 Quality Engineering 2008-12-23 14:26:01 UTC
This issue had *1 votes* before move to platform component


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo