Opened 13 years ago

Closed 13 years ago

#2099 closed enhancement (wontfix)

hide tree context menu items for disabled actions

Reported by: ornus Owned by: bill
Priority: high Milestone: 0.9
Component: Widgets Version: 0.4.1
Keywords: tree Cc: sol@…
Blocked By: Blocking:

Description

in the tree different nodes can have different actions disabled. to show user that some action is disabled corresponding menu items get disabled when context menu is shown. this can lead to situation where user thinks that those actions can be enabled somehow (+ person with poor vision might not notice difference between disabled and enabled item)

as an alternative menu needs to support hiding disabled items.

Attachments (2)

treeV3_19.hideMenuItems.patch (8.4 KB) - added by ornus 13 years ago.
implemented feature. comes with 2 test cases to show both behaviors (disabled and hidden)
treeV3_20.hideMenuItems.2.patch (3.0 KB) - added by ornus 13 years ago.
updated test case to showe menu behavior when all items are disabled. menu becomes invisible, but there's a trace of it when it shows up/hides

Download all attachments as: .zip

Change History (9)

Changed 13 years ago by ornus

implemented feature. comes with 2 test cases to show both behaviors (disabled and hidden)

comment:1 Changed 13 years ago by ornus

the above patch hides disabled items if TreeContextMenuV3.hideDisabledItems is *true*. this attribute can be set directly or through html attribute (see *menu3.html* test case)

comment:2 Changed 13 years ago by bill

Does this issue have anything to do w/the tree in particular? What about disabled menu items on a normal context menu? Also, if you don't want disabled menu items to be shown, then why add them to the menu in the first place?

comment:3 Changed 13 years ago by ornus

the issue is related to the tree.

each node in the tree can have different actions disabled, such as *move*, *detach*, *edit*, etc. idea is to have read only node for example, but that can have child nodes that can be freely edited. basically to have custom logic.

tree can have only one context menu that is associated with the whole tree. so, when the tree context menu opens up it checks the node for which it is shown and disabled items associated with disabled actions. for example if node *edit* action is disabled *Rename* menu item will get disabled too.

as an alternative to this I would like to hide items for disabled actions. so, in the above example *Rename* menu item wouldn't even show in the menu, but only for the specific node that has *edit* action disabled

Changed 13 years ago by ornus

updated test case to showe menu behavior when all items are disabled. menu becomes invisible, but there's a trace of it when it shows up/hides

comment:4 Changed 13 years ago by bill

Let's think about this one some. I agree that different types of tree nodes should have different context menus (just like in Windows Explorer the recycle bin has a different menu than My Documents), but I'm skeptical that we want to support two modes for disabled menu items. It leads to more code, more testing, etc, and from a usability standpoint it might not be something we want to encourage (for example on Windows (AFAIK) there's no option to hide disabled menu items).

comment:5 Changed 13 years ago by Jonathan Bond-Caron

Can a vote be called on this?

I've had to extend the tree menu so that the default is to hide disabled menu items.

I think the point is that TreeV3 should either

a) allow adding multiple context menus b) allow hidding disabled menu items

Try having 30 tree nodes with, 1 node a PDF file, 1 node a Report, 1 node a Text File. It seems clear that I don't want the user to see the different 'disabled' actions each node 'type'. In you use Windows file explorer, you don't get the same menu with disabled items for each file.

It would probably make much more sense to be able to create an unlimited number of context menu's per tree. And have each node bind to a particular context menu. But if I remember reading in the lists, I think it was a perfomance issue of having only 1 context menu per tree.

comment:6 Changed 13 years ago by ornus

I agree. in best case scenario there should be support for different types of nodes and for each type there would be separate context menu, or something similar to that. I'm not sure if there's a performance problem or not, but there will be even more logic and testing for such flexible scenario.

I don't really have time to prototype / implement multiple menus, although that is the solution I would prefer. so I used a simple compromise.

actually in windows it's even more complicated. there's a common part of context menu (shown for every item) and then there's custom part (different for different files). menu shown is a combination of both.

comment:7 Changed 13 years ago by bill

Resolution: wontfix
Status: newclosed

TreeContextMenu? is discontinued in 0.9; need to hook up your own context menus manually by extending the controller.

Note: See TracTickets for help on using tickets.