ok, accepting.

Created attachment 6327 [details]
patch diff for xml module

core side of the bug fixed. temporarily reassigning to xml guys so
that they can review and commit suggested patch. (thanks yarda)

sidenote:
I don't agree with removal of Customize bean action, it's typical case
of cut off of power usage, breaking the vision "common things are
easy, complex possible".
ui team, please, start thread on nbui which justifies this solution,
thanks.

Libor, please review the patch and integrate if you like it. Mark as
fixed then and reassign back. Thx.

I really like this solution. Now XML module's DataLoader ignore system
filesystem XML files except XML templates.

Already integrated. Reassigning back to Dafe.

I forgot to close it. Fixed.

Ian:
Customize Bean is still present in popup, if you disagree 
with the fix, reopen.

verified in [nb_dev](20021016)

Reopening, since I do not agree with the presence of CustomizeBean
action. Will start a thread on nbui as suggested by Dafe, at this
point just reopening so that it is not lost.

Here's the link to the discussion on nbui:
http://www.netbeans.org/servlets/ReadMsg?msgId=391776&listName=nbui

Fixed in [trunk], the core part.
There are still some nodes which have the CustomizeAction, the
annotation type and editor type nodes belong to editor module issue
#28678.
If you find others, assign to related module, or put it here.

core/../projects/SettingsChildren.java 1.18

Please do not close this bug unless it is fixed. If the remaining
parts are in other modules, reassign to that module.

BTW re. removal of CustomizeBeanAction: note that you can still
manually add this action to some global menu (e.g. Edit) and use it
from there if you really want to.

Ian:
 I pointed out the link to the issue which remains in editor module. 
I don't think it is correct that issue should circulate thru modules,
it would break tracking what was fixed and where.

If you prefer, please, create rather dependency tree, with top issue
belonging to ui module pointing to all the relevant ones (in our case
to this one and the editor one).


Jesse: 
 How do you mean it? I think you can't add it to the options node (at
least those ones from core, hopefuly).

I did file this bug as the master bug for this issue, with all the
details how it should look like. If there are subissues for specific
parts of the fix, they should be created as new issues with the
correct dependency added into this issue. Changing the component to UI
and reopening.

Created subissues, for better tracking.

Those:
- System | Filesystem Settings | JavaDoc | items
- System | Filesystem Settings | Java Lib | items

are not fixed yet, from my point of view. Who should fix them?

It's probably XMLDataObject in openide. 

Hello everybody. Aren't we after the UI freeze? Jirka, Ian: does this
mean we should change this part of UI after the freeze? Please confirm
and I will try to find the nodes.

I would like to see it fixed, it's pretty hidden, so I don't think it
will break docs. or any QA tests. Ian, do you agree? 

if it's pretty hidden then  why do we really need to fix it now, that
late?

My reason why this bug should be fixed:
- a good UI is not in several great UI designs, it is mostly about
paying thorough attention to details - like what actions are where in
popup menus. This _is_ important, however silly it may sound from a
non-UI perspective

My reasons why this bug could be fixed now, even though it is after UI
freeze:
- as Jirka points out, the implications of this UI change to docs and
the risk associated is close to zero
- this bug was filed in June 2002, 8 months ago. It is easy to fix (I
assume), so let's get rid of this issue and carry it forward like a
stone tied to our legs, and let's show that we care about UI quality

As always, take this as just my personal, subjective and UI-biased
opinion.

Jirka is right - it can be fixed in XMLDataObject$XMLNode. I will
patch it.

I have removed default action from LookupNode.Leaf
LookupNode 1.28.

Please note that this fix is not complete since the open action is
still present on some nodes. But it has to be further evaluated as to
where the actions should be specified. If I would change e.g.
LookupNode.Leaf to supply own actions I would disable the ability for
modules to provide nodes with their own actions. Which is in turn IMHO
something we don't want to do. Any comments how this can be done in
clever way are appreciated.

Hmm, David do you mean that the fix is not that straight forward?  I
heard you say lookup

The fix would be straightforward if someone
  1. tells me the node where to specify the actions
  2. and at the same time not disable the possibility of being able to
specify own actions for Options nodes

Or change some of the core nodes? I don't know which ones. Please
help! LookupNode.Leaf acts only as filter to custom nodes.

I discussed w/ David today, from what he said my understanding is that
the issue is actually more complex than we thought.  I'd rather us to
spend time on other issues (P1/P2).

I am lowering this to P3.  This was P2 because we didn't want to
forget about it (but we did, the bug was hiding somewhere for long
time before being moved to core).  Otherwise the bug does not qualify
the definition of P2 bugs.

Changed owner David S. -> David K.

Hi, I'm new owner of the datasystem and I would like to ask somebody
from the UI to summarize me what remains to do. This issue is pretty
long and it seems to me that most of the things were already fixed. So
what remains? Thanks in advance.

Please summarize what is needed and assign back to me.

I think that those nodes are only remaining now:


- System | Filesystem Settings | JavaDoc | items
- System | Filesystem Settings | Java Lib | items

On mentioned items there should be this pop-up menu structure:

   Move Up
   Move Down
   ----------
   Cut
   Copy
   Paste
   ----------
   Delete
   Rename
   ----------
   Properties

Both Java Library and Javadoc nodes were eliminated from Options
dialog as part of the new buildsys.

closed