Bug 77386 - Keyboard shortcuts customization not part of the platform
Keyboard shortcuts customization not part of the platform
Product: platform
Classification: Unclassified
Component: -- Other --
All All
: P2 (vote)
: 6.x
Assigned To: David Strupl
: 67561 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-06-05 12:53 UTC by David Strupl
Modified: 2008-12-22 12:12 UTC (History)
14 users (show)

See Also:

Current partial diff (for editor/options mainly) (219.49 KB, patch)
2007-03-22 10:48 UTC, David Strupl
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2006-06-05 12:53:23 UTC
The keyboard shortcuts customization GUI (part of the options dialog) is no
longer part of the core platform but it is part of the editor.

As we don't use editor we miss the global shortcuts configuration dialog. I have
solved it in contrib/tool/optionsKeymap module. This module is a copy-out the
needed functionality from the editor to the standalone module.
Comment 1 David Strupl 2006-06-05 13:06:10 UTC
Sorry I have hit enter before finishing the description ...

The purpose of this issue to bring the functionality back from the editor to
some core module.

I am aware that this will require to provide some small API and an
implementation in core that will be enhanced or replaced by the implementation
in the editor.

As this might require an API review I am trying to Cc: some people who might
give me some hint how this could be implemented.

Any hints and comments are welcomed since I am not really sure from where to
start ;-)
Comment 2 Jaroslav Tulach 2006-06-09 08:11:11 UTC
I guess you want to create a new module which depends on core/options and 
core, provides an option panel for shortcuts and exposes a friend API to 
editor/options which then registers the editor like keys.
Comment 3 David Strupl 2006-06-12 08:04:17 UTC
Ok, I will try to prepare the module in contrib/tool/optionsKeymap in the trunk.
I will try to provide the API there and work on a branch of the editor module.
After I have a working version and after we agree on the API we can talk about
where this module could live outside contrib.
Comment 4 David Strupl 2006-06-12 13:19:08 UTC
Created branch shortcuts_77386 on folder editor/options.
Comment 5 David Strupl 2006-07-11 14:14:30 UTC
Hello everybody,

I have in the trunk of contrib/tool/optionsKeymap a preliminary version of a
friend API that should be part of core and editor/options would register its
implementation there.

Before I go in with the implementation I would like to ask for a look at the
API. I am interested in all comments about the API part of my module. I would
also like ot hear whether and when should I move the module from
contrib/tool/optionsKeymap to core (also to what folder in core?). Any
preferences in package names, class names etc.?

As I currently work on something else there is still some time for this. But I
would like to hear some comments early so i don't spend time on something that
would have to be changed later. I plan to continue to work on this somewhere in
August (2006 ;-).

Thanks for any comments, best regards, David
Comment 6 Marian Mirilovic 2006-08-08 09:08:40 UTC
*** Issue 67561 has been marked as a duplicate of this issue. ***
Comment 7 David Strupl 2006-08-08 09:11:03 UTC
Marian but I will work on this one during this month ;-)
Comment 8 David Strupl 2007-03-04 22:14:53 UTC
Hello everybody,

I have ressurected the work on this issue. Later than expected but better late
than never.

I have brought up to date the branch shortcuts_77386 on editor/options and the
trunk version of contrib/tool/optionsKeymap. The idea is to put the module
optionsKeymap to core (somewhere/where?) and finish the patch.

I would like to ask anyone on the Cc: of this issue to comment on the direction
of this patch,
: there is preliminary friend API in the contrib module. The patch is in no way
finished but I would like you to check what I am doing to stop me before I spend
too much effort in a direction that is hopeless. So can you please help me with

Thanks for any reactions, take care, David
Comment 9 Vitezslav Stejskal 2007-03-05 00:40:24 UTC
Hi David, please let me summarize my understandings:

1. Your contrib module provides an API that can be used by others to access
keymaps (aka profiles) containing a mapping of shortcuts to action Ids.

2. The module will also provide a panel to Tools-Options allowing users to
customize keymaps (it will be the same one currently provided by editor/options,
so once this is in place the editor/options version will be removed).

3. The editor/settings/storage module (currently providing a fried API for
editor/options) will provide an implementation of your API (eg. KeymapManager)
for loading/saving/manipulating the keymaps. So, once this is in place we will
deprecate and possibly remove the friend API from editor/s/s (eg.
KeyBindingSettings factory).

4. The contrib module will also provide a default impl of its own API for
platform applications, which will provide access to global shortcuts.

Am I understanding the direction of proposed changes correctly?
Comment 10 David Strupl 2007-03-05 08:32:29 UTC
Hi Vita, thanks for looking at it.

Actually there is no new code in the contrib module - I have cut out parts of
the editor/options. In release50 we use the contrib module as a standalone
provider of the keyboard shortcuts customization functionality.

Answers to your questions:

1. My current plan was that only editor/options is using the API (friends).

2. Yes, I have removed it on the branch.

3. Not sure about removing the thing from editor/settings/storage - Actually I
don't remember whether I have touched the module when doing my patch back in the
summer 2006. I think I did most of the changes directly in editor/options.

4. Currently the implementation is in EditorBridge extends KeymapManager
directly in editor/options.

Any suggestions as to future direction of the changes is more than welcomed.

Thanks, David
Comment 11 Miloslav Metelka 2007-03-05 08:51:52 UTC
Maybe that's naive but would not it suffice to move the settings-related modules
into platform (not sure how difficult would that be)? The (new) editor settings
(based on MimeLookup) were designed to not be directly tied with the editor
modules (so that other editor impls e.g. emacs or vim emulations) can use them
as well.
Comment 12 David Strupl 2007-03-05 09:00:49 UTC
Mila, thanks for the tip - I can try it, sounds even easier than the current
patch. Which modules are they? editor/settings/ and editor/settings/storage?
Anything more?

By looking at their dependencies they don't look to depend on anything editor

But the functionality that I need is under editor/options (one package there)
and that module depends on editor.

The contrib module is cut of one package from editor/options to a separate
module. It is the GUI panels mainly.
Comment 13 Miloslav Metelka 2007-03-05 09:59:14 UTC
The MimeLookup would be necessary as well, not sure whether anything else
besides the mentioned ones. It's true that the present editor/options depends on
the editor because it still uses the BaseOptions and other old stuff from the
editor that should be further eliminated.
Anyway I leave final decision to Vita, he works on the editor settings now so he
is more eligible than me regarding this.
Comment 14 Vitezslav Stejskal 2007-03-05 16:42:38 UTC
editor/mimelookup is already part of the platform. I think that we have kept the
editor stuff away from the platform so far and it sounds reasonable to me to
keep it away. Technically speaking there would not be a problem to add both e/s
and e/s/s modules to the platform, because they only depend on things that
already belong to the platform. I think this decision should be made by the
platform maintainers or at least should not be made without their approval :).

On the other hand David's original patch looks good to me. More on to that:
#1, #2, #4 - all good
#3 - I was just thinking that maybe we could move the EditorBridge to e/s/s
module, because all it is is just another interface to the editor keybindings
storage. But that would introduce a dependency between e/s/s and the Keymap
Options module, which we probably don't want. Anyway, leaving it in e/o does not
hurt anything.
Comment 15 David Strupl 2007-03-06 08:32:48 UTC

if there is a consensus about the direction of the patch I would like to turn
your attention to smaller details. After the following questions are answered
(agreed upon) I will continue with the work.

a. Where should I put the module? It is currently in contrib/tool/optionsKeymap.
I suggest putting it either under core/optionsKeymap or core/options/keymap. Any
preference? Other suggestions?

b. Should I change the package to something else when moving into the core? If
yes to what?

c. API: any comments regarding the API of the module? Can you give a glance to
the current classes and method signatures?

d. Should I go through fast track API review after the API classes are finished?
Is it necessary for the friend API? Also the question is whether it should stay
as a friend API...

My current plan is to wait for feedback, then finalize the API, write tests, go
through fast track and commit to M8.

Thanks for further assisting me with this. David
Comment 16 Vitezslav Stejskal 2007-03-06 22:36:52 UTC
a. -> I have no strong opinion here, but core/options/keymap would be my choice.

b. -> Either that or change the package in e/o. Two modules can't (well, should
not) have the same package. Perhaps we could move EditorBridge to the
o.n.m.editor.options.keymap package. Anyway, the packaging in e/o does not make
much sense too me, the module contains mostly editor options, but nobody would
guess that from the package names.

c. -> As far as the stability level of this API remains friend I don't have much
comments. Generally the API suffers from some obvious problems, mixing API/SPI,
hardly any javadoc or usecases, etc. But as long as it remains between c/o/k and
e/o only I think it's fine, unless you feel really seriously about it of course.

d. -> Definitely yes. Not that much because of the review itself, but for
advertising the change among people.

Your plan sounds perfect to me. Speaking of the tests I'm adding Max and Jirka
from QE on CC, they might have some tests in qa-functional that will need
updating or perhaps should be migrated to core/options/keymap module.
Comment 17 David Strupl 2007-03-08 08:49:53 UTC
Hello everybody, as there were no other comments I will start the implementation
under core/options/keymap on branch shortcuts_77386. I will move the files so
there are no conflicting packages. After the branch is ready both under core and
editor I will start the review process.
Comment 18 David Strupl 2007-03-20 11:23:47 UTC

I think that the branch shortcuts_77386 is ready for review. I am sorry I did
not attach the diff here since I did not find out how to compare the branch with
the main trunk (and I did try "cvs diff -uN -rshortcuts_77386 core/options
editor/options nbbuild/cluster.properties) - any advice here? (-rHEAD did not
work for me, how do you refer to the trunk?).

I am asking for the review now since I am sure there will be further requests
for changes. Meanwhile I will try to put more tests. Please review the friend
API - please note it is a friend API. I believe that the API cleaning could go
even further, e.g. by eliminating the ShortcutsAction completely from the API
since it is a relict from the days when SystemAction was not Action but I would
like to merge the current changes to the trunk. As the API is friend I think
that the further evolution can happen on the trunk.

Please note that merging the changes from the trunk is rather tedious task when
lot of files has been moved to different modules/packages. That's why I am
asking for the permission to merge to the trunk as soon as possible. I am ready
to fix any outstanding issues afterwards.

Thanks for your attention.
Comment 19 David Strupl 2007-03-21 14:30:51 UTC
I have added some tests and the API_REVIEW keyword - I am not sure whether it is
ok to have just API_REVIEW_FAST or whether both are needed.
Comment 20 Jesse Glick 2007-03-21 22:10:23 UTC
You'll have to figure out what the correct diff command and then tell us,
because only you know how you managed the branch. The closest I can come is

cvs rdiff -u -rshortcuts_77386_root -rshortcuts_77386 core/options/keymap
editor/options nbbuild/cluster.properties > /tmp/shortcuts_77386.diff

You should use rdiff, not diff. This does not accept (or need) -N. core/options
is not branched as a whole, only keymap. The _root tag does not seem accurate
because the patch to cluster.properties is mostly irrelevant stuff. Did you do
some merge after you created the branch? If so, you need to have tagged what you
merged from to serve as the new root; otherwise you cannot do a diff and merge
the branch back in. Doing a diff to HEAD is similarly meaningless because that
mixes in whatever changes have been made in trunk today.
Comment 21 David Strupl 2007-03-22 00:02:47 UTC
As core/options/keymap is brand new I don't think we need any kind of diff
there... I will try to figure out the diff for the editor/options tomorrow.
Comment 22 Vitezslav Stejskal 2007-03-22 02:20:57 UTC
I think you only need API_REVIEW_FAST for fast-tract review, it may get
converted to API_REVIEW if people think that your changes need more thorough

VS01: core/options/keymap should either stop using impl dependencies (on core)
or start using spec.version.base (see the build output); otherwise AU won't be happy

VS02: I am not certain on this, but I thing o.n.api/spi packages are meant
*only* for 'public/stable' APIs. Since the APIs in your module are for friends
(only editor/options at the moment) you probably will have to use some other
packages. You could use names like org.netbeans.core.options.keymap.api/spi or

VS03: KeymapManager.getInstances should be hidden somewhere. Client's are not
expected to call it, are they?

VS04: How is KM.refershActions supposed to be implemented? Please add at least
one sentence to its javadoc.

VS05: Why is ShortcutFinder public? It does not seem to be used by editor/options.

VS06: This is just a nitpic, but why is ShortcutAction part of API? Perhaps we
could move it to SPI and save one package.

The following does not concern the API, but I'd like to mention it anyway.

VS07: ExportShortcutsAction does not seem to be used anywhere. Please delete it.
I wonder if there is somewhere something like ImportShrotcutsAction, but I could
not find it.

VS08: If you delete ExportShortcutsAction you won't need KeymapManager.getName,
I think. This method can be deleted too and constructor adjusted accordingly.
You also will be able to delete XMLStorage, which itself contains a lot of
unused code.

If ExportShortcutsAction is needed, I'd like to know how the export/import
works, because the action seems to duplicate code from editor/settings/storage.

Thanks, David!
Comment 23 David Strupl 2007-03-22 10:36:48 UTC
I am sorry to bother you with stupid cvs questions but this did not work for
some reason:

david@sun:/home/work/trunk-work/nb_all$ cvs rdiff -u -rshortcuts_77386_root
-rshortcuts_77386 editor/options nbbuild/cluster.properties >
cvs server: Diffing editor/options
lock.c:223: failed assertion `strncmp (repository,
current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0'
cvs [server aborted]: received abort signal
lock.c:223: failed assertion `strncmp (repository,
current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0'
cvs [server aborted]: received abort signal

So I will attach the result of
 cvs diff -uN -rshortcuts_77386_after_merge_20070304 -rshortcuts_77386
editor/options nbbuild/cluster.properties > /tmp/shortcuts_77386.diff

and for the core/options/keymap please see the files there - or should I zip
them and attach here?
Comment 24 David Strupl 2007-03-22 10:46:34 UTC
VS01: I will try to change that.

VS02: can someone else try to shed some light on this?

VS03: Ok, I will change that.

VS04: Will fix.

VS05: It is used from MacrosModel and MacrosPanel.

VS06: As I said it might be removed completely. I have no preference whether it
is API or SPI. I am fine with moving everything into one package. Then your
previous comment about missing API SPI distinction will apply again ;-)

VS07: It is used from the layer - most parts were already commented out. There
is only one variant of it still present in the layer. I have moved the layer
fragment from editor/options to core/options/keymap layer.

VS08: I use KeymapManager.getName to identify the instance internally. i am not
sure I am able to delete it. I can look into it. XMLStorage: I thought it was
used from the export actoin - if we don't need that we can most probably delete
the XMLStorage class also.

ExportShortcutsAction - I have no idea whether it is needed or not. It is
mentioned from the commented out layer. If we will never ucomment it - I am more
than happy to delete it.
Comment 25 David Strupl 2007-03-22 10:48:16 UTC
Created attachment 39798 [details]
Current partial diff (for editor/options mainly)
Comment 26 Vitezslav Stejskal 2007-03-22 11:38:53 UTC
VS05: Umm, sorry, find usages didn't seem to find this reference.

VS06: Never mind, leave it as it is.

VS08: Could you use <keyMapManagerImpl>.getClass().getName() instead? If it's
used internally then clients should not be bothered.

XMLStorage: Some part of it is used from ESA, but even then it contains a lot of
unused code.

ExportShortcutsAction: It may sound too drastic, but if it's not used then
delete it without any sentiment. The less code to maintain the better.
Comment 27 Martin Entlicher 2007-03-22 12:06:41 UTC
<Offtopic> FYI: The CVS issue with rdiff is issue #16119. It's there for many
years and still not fixed although they claim it as fixed.
For rdiff to work it's necessary to use an alternate CVSROOT:
Comment 28 David Strupl 2007-03-23 11:07:21 UTC
Hello, can we get some more comments regarding VS02? I would really like to know
which packages should I use before I will continue further. Nobody else willing
to do the review? Thanks a lot, David
Comment 29 Miloslav Metelka 2007-03-23 12:24:01 UTC
Vita is right in VS02, please see
Comment 30 David Strupl 2007-03-30 08:48:21 UTC
Hello, ass there were no other comments I will try to address Vita's comments
(especially the one with the package names - V02) and I would like to commit to
the trunk during the next week. So if you have any further concerns please speak up!
Comment 31 Geertjan Wielenga 2007-04-02 11:20:33 UTC
PLEASE do not remove this action! Please -- (a) many people use it (b) it is
incredibly useful and UNLESS you are going to replace it with the same
functionality, removing it is a REGRESSION.
Comment 32 David Strupl 2007-04-02 11:26:42 UTC
FYI this is the current layer (the same as it was in 5.x):

    <folder name="Actions">
        <folder name="Window">
                <attr name="instanceCreate"
                <attr name="instanceCreate"
                <attr name="instanceCreate"
                <attr name="instanceCreate"
    <folder name="Menu">
        <folder name="File">
            <folder name="Export">
                    <attr name="originalFile"
                    <attr name="originalFile"
                    <attr name="originalFile"
                    <attr name="originalFile"

As you can see the action was (is) not in the main menu, it is accessible only
via defining a shortcut to it. Also there used to be 4 variants while only one
of them is (was) used in 5.x.

Also I would like to know how many is many ;-)

Waiting for additional comments ...
Comment 33 Geertjan Wielenga 2007-04-02 11:42:09 UTC
"As you can see the action was (is) not in the main menu, it is accessible only
via defining a shortcut to it."

So what's the problem? Why don't you just leave it the way it is?
Comment 34 David Strupl 2007-04-02 11:54:30 UTC
Please note that it was Vita's request, so please don't make it personal between
me and yourself. I only said I agree with him. I thought nobody was using the
action - besides you of course. I might be wrong here - so can you please
somehow prove your claim that "(a) many people use it". As I don't have any
proof for my opinion I was asking the whole crowd on the Cc: of this issue for
their comments. Maybe Vita should step forward since he started the whole
argument ;-) I have no problem in leaving it how it is now, just wanted to know
what to do. IMHO the action is useless ... but wait a second --- we now have the
cool gesture collector so we might ask Jarda (or whoever) how many people had
actually used the action in the last couple of months (?).
Comment 35 Geertjan Wielenga 2007-04-02 11:59:56 UTC
Sorry, it is not meant personally. 

I don't see how this shortcut can be seen as 'useless'. If someone changes a
shortcut (e.g., they change 'Ctrl-Shift-N' to something different), then the PDF
keyboard shortcut card is automatically out of date. In this scenario, using
"Export Shortcut" is very useful in generating a new shortcut card.

This is a really common scenario.

I don't know about "many" people using it, but I think if it was more visible
(e.g., as a menu item or toolbar button) there would be "many" people using it.
But people have already left comments in my blog saying that they like this

It makes sense to have it, in some form. I don't care what form that is, but
somehow the user should be able to regenerate an updated keyboard shortcut card.
If you remove this "Export Shortcuts" action, you are removing functionality
that is useful. The scenario above describes a typical situation where it is useful.
Comment 36 Vitezslav Stejskal 2007-04-02 12:50:34 UTC
My only concern in VS07/08 was not to copy dead code. If there is a
functionality that users could use, no matter how dificult it was to reach that
functionality, it should be preserved.
Comment 37 David Strupl 2007-04-02 13:07:20 UTC
Ok, so I am ignoring VS07. Also VS08 as the method getName is used on some
places. I have addressed the other concerns (on the branch). If there are no
more comments I will merge the branch to the trunk tomorrow.
Comment 38 David Strupl 2007-04-03 16:36:28 UTC
Checking in nbbuild/cluster.properties;
/cvs/nbbuild/cluster.properties,v  <--  cluster.properties
new revision: 1.211; previous revision: 1.210
Checking in core/options/keymap/.cvsignore;
/cvs/core/options/keymap/.cvsignore,v  <--  .cvsignore
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/arch.xml;
/cvs/core/options/keymap/arch.xml,v  <--  arch.xml
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/build.xml;
/cvs/core/options/keymap/build.xml,v  <--  build.xml
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/manifest.mf;
/cvs/core/options/keymap/manifest.mf,v  <--  manifest.mf
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/nbproject/.cvsignore;
/cvs/core/options/keymap/nbproject/.cvsignore,v  <--  .cvsignore
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/nbproject/project.properties;
/cvs/core/options/keymap/nbproject/project.properties,v  <--  project.properties
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/nbproject/project.xml;
/cvs/core/options/keymap/nbproject/project.xml,v  <--  project.xml
new revision: 1.2; previous revision: 1.1
RCS file:
Checking in
 <--  org.netbeans.core.options.keymap.spi.KeymapManager
initial revision: 1.1
Checking in
 <--  ShortcutAction.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  ShortcutsFinder.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapManager.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  Bundle.properties
new revision: 1.2; previous revision: 1.1
Checking in
 <--  CompoundAction.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  ExportShortcutsAction.java
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/src/org/netbeans/modules/options/keymap/Keymap.java;
<--  Keymap.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapListRenderer.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapModel.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapPanel.form
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapPanel.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapPanelController.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapViewModel.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  LayersBridge.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  ShortcutsDialog.form
new revision: 1.2; previous revision: 1.1
Checking in
 <--  ShortcutsDialog.java
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/src/org/netbeans/modules/options/keymap/Utils.java;
<--  Utils.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  XMLStorage.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  mf-layer.xml
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/test/.cvsignore;
/cvs/core/options/keymap/test/.cvsignore,v  <--  .cvsignore
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/test/build-unit.xml;
/cvs/core/options/keymap/test/build-unit.xml,v  <--  build-unit.xml
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/test/build.xml;
/cvs/core/options/keymap/test/build.xml,v  <--  build.xml
new revision: 1.2; previous revision: 1.1
Checking in core/options/keymap/test/cfg-unit.xml;
/cvs/core/options/keymap/test/cfg-unit.xml,v  <--  cfg-unit.xml
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapModelTest.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  KeymapViewModelTest.java
new revision: 1.2; previous revision: 1.1
Checking in editor/options/nbproject/project.properties;
/cvs/editor/options/nbproject/project.properties,v  <--  project.properties
new revision: 1.9; previous revision: 1.8
Checking in editor/options/nbproject/project.xml;
/cvs/editor/options/nbproject/project.xml,v  <--  project.xml
new revision: 1.19; previous revision: 1.18
RCS file:
Checking in
 <--  org.netbeans.core.options.keymap.spi.KeymapManager
initial revision: 1.1
Checking in
 <--  CodeTemplatesModel.java
new revision: 1.12; previous revision: 1.11
Checking in editor/options/src/org/netbeans/modules/options/editor/mf-layer.xml;
/cvs/editor/options/src/org/netbeans/modules/options/editor/mf-layer.xml,v  <--
new revision: 1.28; previous revision: 1.27
Checking in
 <--  Bundle.properties
new revision: 1.2; previous revision: 1.1
Checking in
 <--  EditorBridge.java
new revision: 1.2; previous revision: 1.1
Removing editor/options/src/org/netbeans/modules/options/keymap/ActionImpl.java;
<--  ActionImpl.java
new revision: delete; previous revision: 1.3
Removing editor/options/src/org/netbeans/modules/options/keymap/Bundle.properties;
 <--  Bundle.properties
new revision: delete; previous revision: 1.15
Removing editor/options/src/org/netbeans/modules/options/keymap/CompoundAction.java;
 <--  CompoundAction.java
new revision: delete; previous revision: 1.3
Removing editor/options/src/org/netbeans/modules/options/keymap/EditorBridge.java;
 <--  EditorBridge.java
new revision: delete; previous revision: 1.13
 <--  ExportShortcutsAction.java
new revision: delete; previous revision: 1.6
Removing editor/options/src/org/netbeans/modules/options/keymap/Keymap.java;
/cvs/editor/options/src/org/netbeans/modules/options/keymap/Keymap.java,v  <-- 
new revision: delete; previous revision: 1.6
 <--  KeymapListRenderer.java
new revision: delete; previous revision: 1.8
Removing editor/options/src/org/netbeans/modules/options/keymap/KeymapModel.java;
<--  KeymapModel.java
new revision: delete; previous revision: 1.19
Removing editor/options/src/org/netbeans/modules/options/keymap/KeymapPanel.form;
<--  KeymapPanel.form
new revision: delete; previous revision: 1.1
Removing editor/options/src/org/netbeans/modules/options/keymap/KeymapPanel.java;
<--  KeymapPanel.java
new revision: delete; previous revision: 1.28
 <--  KeymapPanelController.java
new revision: delete; previous revision: 1.8
 <--  KeymapViewModel.java
new revision: delete; previous revision: 1.29
Removing editor/options/src/org/netbeans/modules/options/keymap/LayersBridge.java;
 <--  LayersBridge.java
new revision: delete; previous revision: 1.10
 <--  ShortcutsDialog.form
new revision: delete; previous revision: 1.3
 <--  ShortcutsDialog.java
new revision: delete; previous revision: 1.6
Removing editor/options/src/org/netbeans/modules/options/keymap/Utils.java;
/cvs/editor/options/src/org/netbeans/modules/options/keymap/Utils.java,v  <-- 
new revision: delete; previous revision: 1.7
Removing editor/options/src/org/netbeans/modules/options/keymap/XMLStorage.java;
<--  XMLStorage.java
new revision: delete; previous revision: 1.5
Checking in editor/options/src/org/netbeans/modules/options/macros/MacrosModel.java;
<--  MacrosModel.java
new revision: 1.15; previous revision: 1.14
Checking in editor/options/src/org/netbeans/modules/options/macros/MacrosPanel.java;
<--  MacrosPanel.java
new revision: 1.33; previous revision: 1.32
Checking in editor/options/test/cfg-unit.xml;
/cvs/editor/options/test/cfg-unit.xml,v  <--  cfg-unit.xml
new revision: 1.5; previous revision: 1.4
Checking in
 <--  EditorOptionsTest.java
new revision: 1.7; previous revision: 1.6
 <--  KeymapViewModelTest.java
new revision: delete; previous revision: 1.9
Checking in ide/golden/cluster-deps.txt;
/cvs/ide/golden/cluster-deps.txt,v  <--  cluster-deps.txt
new revision: 1.86; previous revision: 1.85
Checking in ide/golden/deps.txt;
/cvs/ide/golden/deps.txt,v  <--  deps.txt
new revision: 1.504; previous revision: 1.503
Checking in ide/golden/files-layout.txt;
/cvs/ide/golden/files-layout.txt,v  <--  files-layout.txt
new revision: 1.226; previous revision: 1.225
Checking in ide/golden/friend-packages.txt;
/cvs/ide/golden/friend-packages.txt,v  <--  friend-packages.txt
new revision: 1.138; previous revision: 1.137
Checking in ide/golden/group-friend-packages.txt;
/cvs/ide/golden/group-friend-packages.txt,v  <--  group-friend-packages.txt
new revision: 1.64; previous revision: 1.63
Checking in ide/golden/modules.txt;
/cvs/ide/golden/modules.txt,v  <--  modules.txt
new revision: 1.128; previous revision: 1.127

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