[Martijn]

No

[null_pointer]

ok, will wait until 18.

[null_pointer]

:-( can not believe I have been hanging out for this change for over a year now.

[takoi]

That is the intended use. The gui is uselessly locked in most cases. as long as the item do not sit in a onscreen container this should be set. I just couldnt change the default as that would break legacy code depending on it.

History is that originally listitems were always backed by a container item but the bindings are now used for much more than building windows. It made sense a long time ago.

Doesn't this open up for the 'legacy code' to use this parameter as well even though they shouldn't, and crash kodi at will?

[ronie]

as long as the item do not sit in a onscreen container this should be set.

i'm afraid i still do not understand when to use offscreen= true and when not to.

some seem to think just about any plugin can set offscreen to true,
while other say it's only for subtitle / scraper type of addons.

hope someone can clarify this.

[Roman_V_M]

hope someone can clarify this.

ironic_monkey = spiff so it as clear as it can be

[ronie]

if it was, i wouldn't have posted my question ;-)
maybe you can clarify what 'as long as the item do not sit in a onscreen container' means?

[null_pointer]

I am going to have a stab at this, Please correct me if I am wrong.

When you create a ListItem in an addon to "send" to Kodi to be displayed it is not on screen yet. You are constructing it, adding settings, adding properties, setting streams info, setting Info Tags, a bunch of calls to various methods to get your ListItem populated with all your data ready to do a xbmcplugin.addDirectoryItems(pluginhandle, dirItems) to have Kodi take these items and display them. They are not on screen items.

The other side to this is when you are working with ListItems in an addon that are already on screen, like when you query a control for a ListItem that is already displayed.
xbmcgui::ControlList::getListItem(index) returnes a ListItem that is ON SCREEN

In Kodi 17 every call to say setProperty or addStreamInfo has to get UI lock, this is not necessary when you are just constructing your ListItems offscreen. So when you are constructing a ListItem you can tell Kodi that this is not on screen yet and dont worry about trying to get a UI lock for method calls that change internal data.

[ronie]

thanx! i get all that ;-)


it's exactly this part that confuses me:

So when you are constructing a ListItem you can tell Kodi that this is not on screen yet

isn't that always the case? or can a listitem that has not be constructed yet already be on screen

perhaps i'm reading things too literally, but since offscreen is specified at construction time (and the listitem can't be on screen at this point, as it doesn't exist yet),
i can't think of a use-case where you would have to set offscreen to false.

[null_pointer]

I think it was done for backwards compatibility.

[spiff]

yes. i could not change the default because it would break scripts relying on it (windowxml stuff). in that case the listitems are directly backed by an item that sit in the gui container. in that case we have to lock the gui so a redraw is not done while we are updating the item.

[ronie]

still struggling to wrap my head around it...

are you saying plugins should set offscreen to true and winxml scripts should not set it to true?

i'm currently using this in a winxml script

python:
listitem = xbmcgui.ListItem('test', offscreen=True)

listitem.setProperty('foo', 'bar')

self.addItem(listitem)

so that is incorrect?

[spiff]

it won't be a problem on add. the problem is when you modify an existing item. maybe it is normal windows and not winxml, i don't recall the details, but at some point you are directly modifying items that sit in a gui control.

[null_pointer]

@ronie
I think the simple answer is yes you can do what you have list there in your post.

If an addon is constructing a ListItem it can ALWAYS use offscreen=True as the ListItem is just being constructed and it is not on screen anywhere.

Internally however (Think ListItems Kodi is reterning from a call) the ListItems are representing something that is on screen and by default the ListItem constructor is have offscreen set to False.

Anywhere in an addon you construct a LitsITem you can set offscreen=True as the ListItem is not on screen anywhere yet.

I think this was said earlier, if the ListItem is representing an on screen item (in a container) then offscreen will need to be False, however to only place you get to set offscreen is in the constructor, thus since this is always at creation time and you can not create a new ListItem in an addon that is already on screen then anywhere in an Addon you can set offscreen to True.
Yes you can query existing list or individual ListItems that are already on screen but you dont get to construct them, that is done internally (in Kodi code) not in your addon. Once you get the ListItem it is already constructed.

[null_pointer]

Thinking about this a little more what about this scenario:
 

Code:

listitem = xbmcgui.ListItem('test', offscreen=True)
listitem.setProperty('foo', 'bar')
self.addItem(listitem)

...

listitem.setProperty('foo', 'Hello')

Does the ListItem get displayed before the next call the setProperty? I would have to dig into the Kodi code to see what happens.