Hitcher described potential issue in http://forum.xbmc.org/showthread.php?t=112767. It looks like bug for me but it might be this way by design. Simplified problematic scenario:
We have controls:
id=1: currently focused, <onright>2</onright>
id=2: hidden, <onright>3</onright>
id=3: hidden, <onright>ExecuteSomeBuiltinFunction</onright>
We have control id==1 focused, press right and currently it works like this:
We're going from control 1 to control 2, control 2 isn't focusable so we're checking where should we go from there. We're going from control 2 to control 3, control 3 still isn't focusable, we don't have navigation path so we simply stop there and in the end nothing is happening. Should we execute builtin from control id==3 or not?
If we should - this PR changes/fixes current behaviour. If not - with some cosmetic changes this can clean <onfoo> handling a little bit, I think.
It's also worth noting that putting them in a grouplist and letting that handle the action doesn't work either.
No more thoughts anyone?
Hi, not trying to be be pushy here but I would like to know whether this will be fixed for Eden so I can make the relevant changes to XeeBo (Eden)?
I would suggest that in the example above, it is not intuitive for the 3rd (hidden) control to execute it's action? I guess it depends on what the action was - if it was an action designed to emulate normal navigation, then it might still make sense. In general, I don't think it does?
But what if all the controls were inside a grouplist? Shouldn't the grouplist's onright ACTION be performed in the above scenario?
Good question. Basically how grouplists work is that the grouplists actions are given to the controls inside the group, rather than executing from the grouplist control itself. For movement in the direction of the grouplist, however, it really only makes sense to give the internal controls navigation actions, and that's also what's done to the controls at the start and end. I suspect this would be possible to change but it might take quite a bit of futzing around.
I presume that atm you have a button that you navigate onto hidden outside the end of the list that has an appropriate action? In some cases this might actually be the cleaner way to execute it?
A little background -
The skin in question is XeeBo and it has a global side menu (which is actually a custom window) that is accessed by moving to the left of any window in the skin. From this menu you can select to go any where you please or, if say you changed your mind or simply wanted to see the little weather panel at the top of the menu, by pressing right return to the window you were in.This is achieved by closing the custom window so control is returned to the last focused control.
Now I've made a skin layout for the TV Next Aired script and obviously want to keep the global menu available via an action - ActivateWindow(51) - but because the script is made up of 7 lists for each day of the week and sometimes there might not be anything airing on one or more of the days I need to be able to open the custom window when they're hidden, and this is where I found my problem.
I've had to use a button for this particular case but it goes against the rest of the skin's navigational feel because it gets focus when returning to the script and not the lists.
Hope that explains things better.
As I think about it, even if we were to change grouplists so that the grouplist action was assigned to the end controls, it still wouldn't fix the problem.
The only fix is treating the actions and navigation as the same, i.e. if you move onto a hidden control, then it will execute it's in all circumstances.
Will review the commits here more thoroughly, as I'm coming around to the idea.
I think once Eden is out and the commits are cleaned up, I'd be happy for this to go in.
Awesome, thanks JM.
change CGUIControl::GetNextAction to more general CGUIControl::GetNav…
don't continue to follow navigation path if we don't have valid id of…
… next control
split GUIAction::Execute into GUIAction::ExecuteActions and CGUIContr…
GUIAction::ExecuteActions will simply execute all non-navigation actions
CGUIControl::Navigate is meant to start navigation from control in given direction until we find focusable control (executing actions on its path)
I did cleanups You pointed earlier. Couldn't really split last commit into 2 because it would break execution of non-navigation actions in in intermediate revision.
Looks good. As this potentially changes navigation paths in existing skins we probably need an xbmc.gui bump?
Resurrection of another stalled pr. Is it in good shape to be merged in August? xbmc.gui bump would propably should go in at the end of merge window?
It's fine to be merged in August - assigned to you.