Bug 40185 - Ability to plug into semantics of F12/S-F12
Ability to plug into semantics of F12/S-F12
Product: platform
Classification: Unclassified
Component: Actions
PC Linux
: P2 (vote)
: 4.x
Assigned To: Jaroslav Tulach
Depends on:
Blocks: 35917 55782 58018
  Show dependency treegraph
Reported: 2004-02-17 16:40 UTC by _ pkuzel
Modified: 2008-12-22 17:47 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT

Workaround in tasklist (I have suggested to copy&paste it to Find Usages) (3.56 KB, text/plain)
2005-03-02 17:19 UTC, _ pkuzel
The changes in openide core and tasklist (43.83 KB, patch)
2005-03-17 14:41 UTC, Jaroslav Tulach
Details | Diff
Includes documentation changes as well as jbecicka's fix of find usages (67.47 KB, patch)
2005-03-22 09:06 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2004-02-17 16:40:25 UTC
is private so it cannot be redefined without
tricks (that may break in next versions). The same
applies to previous jump action.

One would expect these action to be public ones
and in openide.
Comment 1 _ ttran 2004-02-25 14:18:28 UTC
please provide the use case.  What you're asking for is the solution,
we need to know what is the problem.  BTW this is not a bug
Comment 2 _ pkuzel 2004-02-25 15:51:06 UTC
Next action is generic concept, compare to IDEA. It cannot be
implemented in NetBeans because it's private in core. So no other
module can set action performer without using reflection (it's
hopefully on classpath :-).
Comment 3 Jesse Glick 2004-03-16 17:20:03 UTC
Impl in core/output, not core/compiler.
Comment 4 _ tboudreau 2004-03-17 10:44:18 UTC
Passing to openide/actions - the output window can certainly implement whatever Next 
action API is created, but it needs an API.

Petr, can you explain what you would do with a generic Next action once you had it?
Comment 5 _ pkuzel 2004-03-18 08:48:25 UTC
I want to remove
Comment 6 _ tboudreau 2004-03-18 11:07:18 UTC
Petr, since you seem to be driving this, could you propose the API you'd like to have for 
this and provide some demo implementation?
Comment 7 _ pkuzel 2004-03-18 12:42:51 UTC
Yes, move core/output/src/org/netbeans/core/output/NextOutJumpAction.java
to openide.actions. Even better the action could be turned to
CookieAction with supporting cookies:

  interface NextCookie {
     public void navigateToNext();

and (respectively):

  interface PreviousCookie {
     public void navigateToPrevious();
Comment 8 _ tboudreau 2004-03-18 17:33:33 UTC
Sounds like creating a patch for it and going through dev-rev would be a good next step.
Comment 9 _ pkuzel 2004-03-18 17:44:32 UTC
It's RFE to core team. I do not plan to implement it, sorry.
Comment 10 _ tboudreau 2004-03-18 18:03:44 UTC
Fair enough.
Comment 11 _ pkuzel 2004-03-22 09:32:24 UTC
Let me restore original priority, The hack (flaky reflection to core)
uncovers API deficiency that should be resolved. 

Comment 12 _ pkuzel 2004-07-15 10:30:19 UTC
Cookie action is not s good idea here because it's too contextual.
Setting action performer is better. It can be done indirectly (and
assuring cooperation between several Next action performer providers)-
excerpt from Jesses's comment on issue #35917:

Better action enablement logic would probably be based on having the
real action (global KB and menu binding) track open TopComponent's
whose ActionMap's bind a well-known key to a performer, and delegate
to the binding of the last such TC to be focussed. Or something along
those lines. In any event, this would work with or without sliding
mode since it does not require the TC to be visible at the time its
binding is processed.

The same logic could of course be used for Output Window hyperlinks,
Search window hits, Where Used usages, etc
Comment 13 Jan Chalupa 2004-11-01 16:56:28 UTC
Re-assigning Tim's issues to Dafe.
Comment 14 _ pkuzel 2005-03-02 17:08:33 UTC
Blocks Find Usages results navigaton (issue #55782).
Comment 15 _ pkuzel 2005-03-02 17:19:34 UTC
Created attachment 20631 [details]
Workaround in tasklist (I have suggested to copy&paste it to Find Usages)
Comment 16 Martin Matula 2005-03-03 13:20:24 UTC
Changing to DEFECT and reassigning to Yarda (after discussion with him).
Comment 17 Jaroslav Tulach 2005-03-03 16:23:38 UTC
Milosi, please help! I guess the solution is similar to the "select
prev/next tab", what is its issue number? Thanks.
Comment 18 Milos Kleint 2005-03-04 10:15:34 UTC
#50297 for output, similar issue was for multiview tabs, but cannot
find it.
Comment 19 Jaroslav Tulach 2005-03-17 14:39:28 UTC
Dear reviewers, I have prepared raw diff of suggested changes and I'd like you
to tell me whether they are acceptable or not and Martin to try whether they
work for him.

I would split my changes into three categories:

1. focus change surviving CallbackSystemAction & ActionMap 

There was a missing implementation of communication between
CallbackSystemActions that return true from surviveFocusChange and ActionMap,
basically this did not work. My changes in org.openide.util.actions fix the
problem, now there is special ActionMap that keeps the history of changes and is
queried when the actual component does not provide own binding for the action.

2. JumpNextAction

I moved the "next" action from output2 into core and as it is supposed to be
useful in platform also, I registered it under Edit submenu in core/ui, in order
to keep the ide state as it is now, I masked and reregistered it in core/ide to
BuildProject (which is not present in platform at all). Now the strings
"JumpNextAction" and "JumpPrevAction" are part of API provided by core (I'll
document that before integration) and can be used by any module to register
their own actions into their TopComponent action maps - this is what I did in
core/output2 and tasklist. Changes in these modules in fact remove fragile
reflection, focus and time dependant code and replace it with simple
getActionMap().put(...) and I consider them very healthy.

3. requestVisible 

However during my implementation I faced unexpected problem - the output window
registers its performers without getting focus. This usecase was not solved in
the original proposal, so I had to invent new solution for it. I decided to use
requestVisible as it was already used in output tab and fact seems to be used
exactly in the situations where one wants the user to notice the window and make
it functional (e.g. register global bindings). So I changed the
TopComponent.requestVisible() to also "flash" the content of
Utilities.actionsGlobalContext() with a new ActionMap for a while (just few ms)
and let all CallbackSystemAction surviving focus know that the ActionMap now
belongs to their history ActionMap. This is slightly controversial fix as it
starts to use a method for new purpose, but I think it is correct and cannot
break anything: until now, CallbackSystemActions with surviveFocusChange used
only setActionPerformer and this still takes precedence over ActionMap, the
ActionMap itself did not work for them and the CallbackSystemActions without
surviveFocusChange shall not be affected as they do not use the history map for
searching and thus they will get the same results as before.

I'd like to provide final patch on Tuesday and it will contain tests for
JumpAction's keys, changes in arch documents of tasklist, output2 and core,
apichanges of openide and javadoc of TopComponent.requestVisible. If there are
any objections against these changes, please let me know before then, so I do
not waste the time on documentation. I'd like to integrate on Mar 24.
Comment 20 Jaroslav Tulach 2005-03-17 14:41:30 UTC
Created attachment 20925 [details]
The changes in openide core and tasklist
Comment 21 _ pkuzel 2005-03-17 15:37:53 UTC
> Now the strings "JumpNextAction" and "JumpPrevAction" are
> part of API provided by core.

In attached diff I do not see any manifest (project.zml) dependencies section
update. I'd expect new ugly dependency on core. Could you move to openide.actions?
Comment 22 Jan Becicka 2005-03-18 10:04:58 UTC
Thanks for your patch, jardo!
I have two issues regarding your patch:
1. (Really minor)
[org.netbeans.core.projects.cache #6] Warning: layer
contains duplicate files named

It is possible, that some minor bug is on my side...

2. I created patch, that fixes issue 55782. I tested my code and observed
following incorrect behavior:
1. I did Find Usages - F12 correctly jumped through my usages
2. I did some errors in code and did Build leaving Find Usages opened - output
window with errors appeared, but F12 still jumps through my usages. But when I
use mouse and click Output Window - F12 correctly starts to jump through errors.
Not sure where is the problem.
Comment 23 Jaroslav Tulach 2005-03-21 14:03:54 UTC
Re. "Ugly dependency on core" - I do not want to introduce dependency on core,
but I also do not want to introduce new subclass of NodeAction into
openide/actions. It would be acceptable to add a factory method:

public static ContextAwareAction jumpNext ();

somewhere (however I do not know where!) and in future replace its
implementation to not use NodeAction, but just some action without creating new
class. But as I do not know where to put such action, I'd rather prefer to stick
with it being in core. I'll update arch*actions to mention the keys and write
tests in core to verify that the key really works as expected. I hope this will
be acceptable.

Re. patch & comments from jbecicka: I'll fix the layer warning and find out what
is wrong in cooperation between usages and errors.
Comment 24 Jaroslav Tulach 2005-03-22 09:06:24 UTC
Created attachment 21018 [details]
Includes documentation changes as well as jbecicka's fix of find usages
Comment 25 Jaroslav Tulach 2005-03-22 09:07:42 UTC
I'd like to integrate tomorrow. 
Comment 26 Jaroslav Tulach 2005-03-23 07:27:03 UTC
cvs ci -m "#40185: Making callback actions surviving focus change work correctly 
with ActionMaps, defining 'jumpNext' and 'jumpPrev' keys, using them in output2, 
tasklist and refactoring" 
Checking in ant/src/org/apache/tools/ant/module/resources/AntModuleLayer.xml; 
/cvs/ant/src/org/apache/tools/ant/module/resources/AntModuleLayer.xml,v  <--  
new revision: 1.33; previous revision: 1.32 
Checking in core/ide/src/org/netbeans/core/ide/resources/layer.xml; 
/cvs/core/ide/src/org/netbeans/core/ide/resources/layer.xml,v  <--  layer.xml 
new revision: 1.16; previous revision: 1.15 
Checking in core/output2/src/org/netbeans/core/output2/Bundle.properties; 
/cvs/core/output2/src/org/netbeans/core/output2/Bundle.properties,v  <--  
new revision: 1.10; previous revision: 1.9 
Checking in core/output2/src/org/netbeans/core/output2/Controller.java; 
/cvs/core/output2/src/org/netbeans/core/output2/Controller.java,v  <--  
new revision: 1.32; previous revision: 1.31 
Checking in core/output2/src/org/netbeans/core/output2/IOEvent.java; 
/cvs/core/output2/src/org/netbeans/core/output2/IOEvent.java,v  <--  IOEvent.java 
new revision: 1.5; previous revision: 1.4 
Checking in core/output2/src/org/netbeans/core/output2/OutputWindow.java; 
/cvs/core/output2/src/org/netbeans/core/output2/OutputWindow.java,v  <--  
new revision: 1.14; previous revision: 1.13 
Checking in core/output2/src/org/netbeans/core/output2/layer.xml; 
/cvs/core/output2/src/org/netbeans/core/output2/layer.xml,v  <--  layer.xml 
new revision: 1.13; previous revision: 1.12 
Checking in core/output2/src/org/netbeans/core/output2/ui/AbstractOutputTab.java; 
/cvs/core/output2/src/org/netbeans/core/output2/ui/AbstractOutputTab.java,v  <--  
new revision: 1.5; previous revision: 1.4 
Checking in 
<--  AbstractOutputWindow.java 
new revision: 1.10; previous revision: 1.9 
Checking in core/src/org/netbeans/core/actions/Bundle.properties; 
/cvs/core/src/org/netbeans/core/actions/Bundle.properties,v  <--  Bundle.properties 
new revision: 1.141; previous revision: 1.140 
RCS file: /cvs/core/src/org/netbeans/core/actions/JumpNextAction.java,v 
Checking in core/src/org/netbeans/core/actions/JumpNextAction.java; 
/cvs/core/src/org/netbeans/core/actions/JumpNextAction.java,v  <--  
initial revision: 1.1 
RCS file: /cvs/core/src/org/netbeans/core/actions/JumpPrevAction.java,v 
Checking in core/src/org/netbeans/core/actions/JumpPrevAction.java; 
/cvs/core/src/org/netbeans/core/actions/JumpPrevAction.java,v  <--  
initial revision: 1.1 
file: /cvs/core/test/unit/src/org/netbeans/core/actions/ActionMapKeysTest.java,v 
Checking in core/test/unit/src/org/netbeans/core/actions/ActionMapKeysTest.java; 
/cvs/core/test/unit/src/org/netbeans/core/actions/ActionMapKeysTest.java,v  <--  
initial revision: 1.1 
Checking in core/ui/src/org/netbeans/core/ui/resources/layer.xml; 
/cvs/core/ui/src/org/netbeans/core/ui/resources/layer.xml,v  <--  layer.xml 
new revision: 1.89; previous revision: 1.88 
Checking in openide/api/doc/changes/apichanges.xml; 
/cvs/openide/api/doc/changes/apichanges.xml,v  <--  apichanges.xml 
new revision: 1.238; previous revision: 1.237 
Checking in openide/arch/arch-openide-actions.xml; 
/cvs/openide/arch/arch-openide-actions.xml,v  <--  arch-openide-actions.xml 
new revision: 1.28; previous revision: 1.27 
Checking in openide/src/org/openide/util/actions/CallbackSystemAction.java; 
/cvs/openide/src/org/openide/util/actions/CallbackSystemAction.java,v  <--  
new revision: 1.39; previous revision: 1.38 
Checking in openide/src/org/openide/windows/DelegateActionMap.java; 
/cvs/openide/src/org/openide/windows/DelegateActionMap.java,v  <--  
new revision: 1.7; previous revision: 1.6 
Checking in openide/src/org/openide/windows/TopComponent.java; 
/cvs/openide/src/org/openide/windows/TopComponent.java,v  <--  
new revision: 1.140; previous revision: 1.139 
Checking in 
<--  CallbackSystemActionTest.java 
new revision: 1.12; previous revision: 1.11 
Checking in openide/test/unit/src/org/openide/windows/GlobalContextImplTest.java; 
/cvs/openide/test/unit/src/org/openide/windows/GlobalContextImplTest.java,v  <--  
new revision: 1.7; previous revision: 1.6 
Checking in 
<--  GlobalActionContextImpl.java 
new revision: 1.5; previous revision: 1.4 
Checking in 
<--  layer.xml 
new revision: 1.48; previous revision: 1.47 
Checking in refactoring/arch/arch-refactoring.xml; 
/cvs/refactoring/arch/arch-refactoring.xml,v  <--  arch-refactoring.xml 
new revision: 1.15; previous revision: 1.14 
Checking in refactoring/nbproject/project.xml; 
/cvs/refactoring/nbproject/project.xml,v  <--  project.xml 
new revision: 1.17; previous revision: 1.16 
Checking in 
<--  CheckNodeListener.java 
new revision: 1.11; previous revision: 1.10 
Checking in 
<--  RefactoringPanel.java 
new revision: 1.48; previous revision: 1.47 
Checking in 
<--  RefactoringPanelContainer.java 
new revision: 1.15; previous revision: 1.14 
Checking in tasklist/arch/arch-tasklist-core.xml; 
/cvs/tasklist/arch/arch-tasklist-core.xml,v  <--  arch-tasklist-core.xml 
new revision: 1.9; previous revision: 1.8 
Checking in tasklist/core/nbproject/project.xml; 
/cvs/tasklist/core/nbproject/project.xml,v  <--  project.xml 
new revision: 1.3; previous revision: 1.2 
Checking in tasklist/core/src/org/netbeans/modules/tasklist/core/TaskListView.java; 
/cvs/tasklist/core/src/org/netbeans/modules/tasklist/core/TaskListView.java,v  <--  
new revision: 1.118; previous revision: 1.117 
Comment 27 Jan Chalupa 2005-03-26 09:20:55 UTC
The fix from 2005-03-23 seems to cause 56986. It should be reverted and reviewed
Comment 28 Jaroslav Tulach 2005-04-03 07:12:19 UTC
I believe I found and integrated simple fix for issue 56986 (I'll verify later
today). If it worked and if we did not know about any other problems related to
this integration I'd prefer not to rollback it.
Comment 29 Jan Chalupa 2005-04-03 09:17:58 UTC
Issue #56986 is fixed now. I'm not aware of any other problems caused by the
previous fix to this issue. I'm changing its status back to RESOLVED.
Comment 30 John Jullion-ceccarelli 2005-04-06 13:38:28 UTC
I have been scanning this issue and can't figure out why it has a UI keyword. Is
there a UI change here that needs to be documented?
Comment 31 Jesse Glick 2005-04-06 18:38:35 UTC
I think there is a UI change, though whether it needs documentation is
questionable, since it should just be intuitive. Basically, F12 and S-F12 should
now operate smoothly across all appropriate windows - output, refactoring,
tasklist - always operating on the last such window to receive focus (or be opened).

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