The Help button in the Options window transfers
focus away from the selected node or property
sheet and back to the Options window itself. That
means that if you select any node and click the
Help button, you'll get the
org.netbeans.core.actions.OptionsAction null help
ID. So effectively CSH for all Options windows
nodes is broken, even though selecting the node
and pressing F1 works.
This should be fixed on the property panel rewrite branch - as a fix
for another bug, the help button is no longer focusable - so it
shouldn't affect focus at all when you click it (this is okay, there
is a keyboard shortcut - F1, so the button itself does not have to be
Property panel rewrite branch merged.
branch was merged but problem's still there.
org.openide.explorer.propertysheet.DescriptionPanel line 111:
It couldn't steal focus if it wanted to - it can't be focused. What
do you mean?
OK, let me be more clear. Before the new window system and property
sheet introductions, the Help button on the Options window displayed
the help for the node that was selected. Now it just shows the help
for the Options window.
I also once got it to show the help for the node it was on (Ant
Settings). It then got stuck on that help ID, so that no matter which
node you selected and pressed F1 you got the help for Ant Settings.
Which help button - the one on the property sheet or the one at the
bottom that says "help"? I have not touched the code that affects the
help button in the options dialog. Nothing should have changed there.
The one at the bottom that says Help.
Reassigning this to Peter - winsys integration caused this bug. How
Open View | Properties. Open the options window. Notice the main
property sheet is not changing - the Options dialog no longer sets the
global node selection.
Either fix the help button to track the TTV's selected node or fix the
options dialog so it will affect the global node selection.
Maybe want an HIE option - there are now two help buttons. The one in
the property sheet does work correctly; the one at the bottom of the
adding UI keyword and Jano as a CC.
Well, I don't know how it was before, but now it seems to me it is
1) If you select some node in options and press F1.. you get the help
connected to the node (if available).
2) If you press help button on options window you get the help about
options dialog (doesn't matter what is selected there).
You demand that in case of 2) you get the help to selected node.. but
I think that's wrong, the help button is set clearly in context of
entire dialog, not the explorer selection. How you would get the help
to options dialog, just to rely it falls back when node doesn't
Passing to Jano to decide.
Unfortunately, according to most tests, nobody knows about F1 or uses
it. Besides, I think the information users are most likely to need
help on is the properties, and not the Options window itself.
The two help buttons look kind of weird right on top of each other but
there were two help buttons in 3.5 too. I'm fine with HIE looking at
this but IMHO this is a clear regression and should be returned to the
way it worked before.
Sorry, inadvertently changed the subcomponent
My point of view:
The "Help" button should be context sensitive to currently selected
node in options tree. Presence of small help button in property sheet
is just a side effect of reusing the property sheet component in this
dialog. In a future, we would hopefully have a customizer panel with
regular components (not the property sheet). In that case the help
button would of course display help of the currently selected options
category. Please, have a look at the Mozilla's Prefererences dialog,
which has context sensitive help button.
To improve access to the general options dialog help, it should
probably be linked from each contextual help page shown in help window.
OK, that's what you desire.
Now I will need to investigate the API, because I've got a feeling
current DialogDescriptor API don't offer something like that...
Do you know about another such dialog example where it works the
desired way in NB?
I decrese the priority, from my point of view this is far from being
No1 problem now.
Sorry, I really consider this to be a regression from the previous
state. It needs to be addressed. As a P3, this might easily slip
through the cracks. P3->P2.
In my opinion this shouldn't be considered a regression.
Option component was before as a separate floating window which
managed its help button. Now it was changed, as it was required by
spec, to dialog. Now the help button is provided by that dialog API
impl.. I'm not sure at this moment, but it seems that API doesn't
offer what you desire... anyway there are new circumstances, why then
the regression? Are you going to fire a regression that it is not a
floating window too?
Also even if it is a regression, why P2? I think issues priority means
its importance... and this is not the most important issue now, I'm sure.
An argument that if it is p3 it wan't be solved sound silly.
I'm sorry that the spec did not anticipate the effect on the helpID
behavior. However, that does not change the fact that it is a
regression from the user's point of view.
guys, please don't argue over if it's P2 or P3, nor if it's regression
or not. Help stops working, which is a serious problem. We should fix
it even if it's P5.
I'm not arguing, that's OK if you think is P2.
Help didn't stop working, it is still working, it is just about how it
Fixed in [trunk]