Kodi Community Forum

Tested and everything works as it should

Edit:
"500 Label 32071 / 32072 Window Title"
Can this be extended to display the choosen group by the "group=$foo" value? And if yes, also with an override possibility?

I want to display the group name to the window title system.
If the group is "discwidgets", it should display "Disc Widgets - Edit" for example.

It would be enough if the container 211 would provide the property(group) to use the stringcompare method for it.

Thanks both. Always good to know bugs are squashed

(2014-06-22, 08:49)sualfred Wrote: [ -> ]"500 Label 32071 / 32072 Window Title"
Can this be extended to display the choosen group by the "group=$foo" value? And if yes, also with an override possibility?

I want to display the group name to the window title system.
If the group is "discwidgets", it should display "Disc Widgets - Edit" for example.

It would be enough if the container 211 would provide the property(group) to use the stringcompare method for it.

The window isn't aware of the actual name of the group being edited, but I would think this (or an override) could be passed to the window while opening. I'll have a play with what can be done.

The group will be 211's labelID property (the labelID is how the script identifies menuitems and their submenus internally). The name of the group its label.

Edit: Is what's on Git now what you wanted? The group name is passed in, saved in window property "groupDisplayName", displayed in label 500 and can be set to something else by setting window property "overrideName" before passing a click to button 405 to edit submenu...?

I've got a more personal request for the skin I'm currently working on (Substratum) to get the main menu and sub menu working across the skin.

Can you add ID numbers to the items generated in the includes file please?

Thanks.

Sure. Any particular range?

(Just to be clear, you mean <item id="int" />, right...?)

Yeah that's correct.

Doesn't matter as long as the first one starts at 0, then 1, and so on; also the same entry has the same ID for each user.

ie


The reasoning behind this so when we open a new window it loads the main menu and sub menu includes and I can set they're respective focus to the current windows contents.

Many thanks.

(2014-06-22, 15:41)Hitcher Wrote: [ -> ]Yeah that's correct.

Doesn't matter as long as the first one starts at 0, then 1, and so on; also the same entry has the same ID for each user.

ie

PHP Code:

snip 


The reasoning behind this so when we open a new window it loads the main menu and sub menu includes and I can set they're respective focus to the current windows contents.

Many thanks.

By "the same entry has the same ID for each user" you just mean start counting again from zero for that users menu entries? If so, that's perfectly doable. If you mean that each user should have the same id for their entry to, say movie titles, then again that's doable but harder. If you mean all users on all systems should have the same id for their entry to movie titles, then that's nigh impossible

But I'm assuming that your plan is to set where the focus was when closing a window, and reset the focus again when opening one. If that's right, I'm hoping you just mean the first solution (And I'm also going to take your word as a highly skilled skinner that the possibility of one of these items having the same id as another control in a window won't cause issues )

Actually you can hold off until I do some more testing as getting the id (as opposed to the position) and then focusing on those values is proving harder than I thought.

I'll report back later.

Cheers.

Sounds not too disimilar from trying to get reFocus' menu to focus correctly when hiding the submenu items. In the end it prooved easier to use the script to scan through the list items to find the one with the right property and set focus, rather than doing it skin-side. Just something to think about whilst you get your solution.

I've got it working using different methods but they all fail when the number of items in the list exceed the number visible and the list gets offset so when you open a new window it focuses on the correct item but the list layout is reset.

Yup, that was one of the problems with reFocus when trying to do it skinside. The other being trying to do it based on original menu item location (actually not that disimilar from an ID property) which didn't take into account hidden items. Frustrated me for ages till I had a moment of inspiration and did it in six lines of python.

I'm beginning to think it's going to be impossible to achieve without restricting the number of items in each list - is that possible with the script or will we have to drop support for user customization altogether?

Nope, no support for limiting number of items. And, as I can't think of a sane way to do that, as ultimately the menus are supposed to be able to be shared across strings, Its unlikely to be added.

Hello, I'm currently trying adapt your script info my skin mod and found that item ids asked for by Hitcher will be helpful (because of slightly different list behavior) for me too. Are you still planing to add them or did you scraped idea? I'm not 100% sure from last comments in this thread .

I had shelved it but, as you've asked, I've just pushed the code for item id's to git.

Are they separated into their respective groups for numbering?

EDIT: Tested myself and they are indeed, cheers.