Lory171
commented
5 years ago Hm, did you try to use nk_popup_begin and friends first? I can't comment more without seeing your source code, but I would say there shall be no need for any bounds for use cases you've described.
The problem is not using nk_contextual or nk_popup, it's the fact that getting the area (position and size) of some widgets with precision it's not possibile, neither calculating it nor getting it with nk_widget_bounds, as you said the API it's not meant for this. The area is needed for both nk_contextual and nk_popup, as you need to know which area trigger the activation of the popup.
The problem with the tree widget it's that the allocation of space it's not controlled by the user but it happen inside the function call. Using nk_widget_bounds before gives you the area value of the last widget before the tree, using it after gives you the area in the next row. I think this can happen also with other complex widgets.
For my project I needed to open a contextual menu when right clicking a tree node, but finding the widget bounds for the tree widget it's not possible with nuklear API and calculating them with precision from outside it's a mess. While the
nk_tree_element_xxxfunctions let you know if a tree node has been selected, it doesn't give you the bounds of the selection. I added exactly this, it may be useful for other situations like custom drawing on the node when selected. I can write a different function just for this behaviour so to not change the current API, but I think it's right to have it in the selectable tree widget. Feel free to close this pull request if you don't like the change.