[Hitcher]

I'm actually using a grouplist for this now filled with the info from the buttons; I've also solved the alignment problem using the origin positions based on whether certain buttons are visible or not.

Having said that, a proper grouplist would be welcome.

[pieh]

I'm more than happy with that solution the only other issue we had was too many items needing scrolling like in hitchers screenshot but the eden code has already removed a heap of those buttons

After few thoughts: IMO problem here is amount of items rather than lack of scrolling ability. If context menu is growing too big then IMO it need to be redesigned somehow - I think that all available options should be visible without scrolling ... I hope that after post-dharma context menu cleaning this is no longer issue?

I'm actually using a grouplist for this now filled with the info from the buttons; I've also solved the alignment problem using the origin positions based on whether certain buttons are visible or not.

Having said that, a proper grouplist would be welcome.

Do You need grouplist to achieve something more than <itemgap>? Allowing to set itemgap (without grouplist, as said in post #14) would work for You?

[Jezz_X]

I'm actually using a grouplist for this now filled with the info from the buttons; I've also solved the alignment problem using the origin positions based on whether certain buttons are visible or not.

Having said that, a proper grouplist would be welcome.

but do you really need a grouplist or would you rather just set the button gap ?

[Hitcher]

Actually you're both right, allowing us to set the item gap would remove the need for me to use a grouplist.

Thanks.

[jmarshall]

From a code perspective utilizing a grouplist seems a much easier way to go - it already handles all the navigation between controls and spacing of buttons etc so most of the UI-specific stuff in the contextmenu dialog can be ripped out. All we need is the sizing of the backdrop as already occurs. That can also be done with a single image rather than 3 I believe, thus ripping out even more code (easier for you guys as well - no need for 3 controls and 3 textures).

As far as I can tell there's no disadvantage to using a grouplist and a single image for the background.

Cheers,
Jonathan

[pieh]

heh, I must say I was little lost here

Jezz_X: now I think I got what You meant - if we will have grouplist nothing will stop You from putting CloseDialog button somewhere there (as in any other .xml). Idea is that only 2 controls would be hard coded - grouplist for buttons and background that would stretch to cover grouplist area. You are free to add any other controls (just hope I won't see any flying pink rectangles there!)

[`Black]

If there would be a grouplist, it would be nice if we could set a fixed max height for the context menu so that the list will scroll if there are too many elements.

[pieh]

plan is to add <height min="xx" max="xx">auto</height> (and same with width) to grouplist - it will benefit more areas

[pieh]

Update - from next nightly:
<height min="xx" max="xx">auto</height> (and same with width) was added to grouplist. In fact <height>XX</height> is just shortcut to <height min="0" max="XX">auto</height> (this is important in context menu because using <height>xx</height> will limit height of grouplist to that value)

See https://github.com/xbmc/xbmc/blob/448cc1...xtMenu.xml how new context menu dialog *should* look like.

Of course You can still use old way - but this is depracated and will propably be removed after eden - so if You're creating new skin - go with new way.

[pecinko]

Not necessarily related to context menu - Could you use just "auto" in a grouplist, without defining MIN and MAX i.e. Will grouplist auto calculate height based on number of visible items and their height?

[`Black]

If you have e.g. <height min="60" max="420">auto</height>, button height 60px and there are 4 buttons in the grouplist, the grouplist will have a height of 240px and will be centered within the dimensions of the background image.

[Hitcher]

if we will have grouplist nothing will stop You from putting CloseDialog button somewhere there (as in any other .xml). Idea is that only 2 controls would be hard coded - grouplist for buttons and background that would stretch to cover grouplist area. You are free to add any other controls (just hope I won't see any flying pink rectangles there!)

Only just got around to changing my Context Menu but I've run into a problem.

I've have the 'Close' button at the bottom of the list but placing it after the default button control in the grouplist doesn't then place it after the buttons as I would have expected. Instead it's being placed in front of them.

EDIT: Images added.

Previously -



Now -

[pieh]

@Hitcher
We didn't exactly check where template button is - we simply were adding buttons to the list. 277fc2f4 fixes this - hopefully it will be backported to eden.

[Hitcher]

Many thanks.

[Hitcher]

As reported in GitHub the default control seems to be hard-coded to button 1000 which means any added buttons that appear at the top of the grouplist are by-passed in favour of this button.

Either the default control should be changed to the actual grouplist or it should be left up to the skinner via 'default control'.

Thanks.