WindowXML changes
#16
(2012-09-23, 15:52)jfcarroll Wrote: There is one difference to note. The old system used to raise a "TypeError" in python when this happend. Now a RuntimeError is raised. Maybe that explains why you notice a difference?

Ok, that could very well be. I will check and let you know.
Reply
#17
(2012-09-23, 16:59)Basje Wrote:
(2012-09-23, 15:52)jfcarroll Wrote: There is one difference to note. The old system used to raise a "TypeError" in python when this happend. Now a RuntimeError is raised. Maybe that explains why you notice a difference?

Ok, that could very well be. I will check and let you know.

Yes, that was the issue. In some skins that control was not available and that is why I caught the error. So that is fixed now. But now I get this error:

Code:
TypeError: argument "item" for method "addItem" must be unicode or str

When I call
Code:
self.addItem(tmp)

where tmp is an xbmcgui.ListItem. This used to be right, but apparently not anymore?

Is there a place were I can read up with the changes in the WindowXML stuff? So I don't have to ask these (stupid) questions.
Reply
#18
Ah. This would be an issue I caused. addItem has been a pain. Let me take a look. Thanks for your patience.
Reply
#19
Oh. They're not stupid questions. You're helping us work through the next generation plugin engine, which should make expansion much easier and even eventually allow other scripting languages.

The PR that's the root of these issues is here: https://github.com/xbmc/xbmc/pull/901
The wiki writeup is here: http://wiki.xbmc.org/index.php?title=Cat...generation

The code is supposed to be backward compatible. If it makes a big difference I could raise a TypeError instead of a RuntimeError (but actually a TypeError is wrong).

I'll get back to you on addItem shortly.
Reply
#20
Ok. Looking at the code it's not obvious how this is possible. Can you tell me how to get this error to happen in your script?
Reply
#21
(2012-09-24, 00:19)jfcarroll Wrote: Ok. Looking at the code it's not obvious how this is possible. Can you tell me how to get this error to happen in your script?

This is how my code looks:

Code:
tmp = xbmcgui.ListItem(channelGUI.channelName,"" , channelGUI.icon , channelGUI.iconLarge)
tmp.setProperty("XOT_ChannelDescription", channelGUI.channelDescription)        
self.addItem(tmp)

If you want I can PM you a new version of my script so you can test it.

EDIT: besides that: if I add XOT-Uzg.v3 on the Home screen as a quick launch, it won't start if there are no .pyo or .pyc files. I can run it from Videos -> Add-ons and then after the first full run (and all .pyo and .pyc files are created) it seems to work fine. This started after the change in this TRAC issue: http://trac.xbmc.org/ticket/13325#comment:4
Reply
#22
Quote:EDIT: besides that: if I add XOT-Uzg.v3 on the Home screen as a quick launch, it won't start if there are no .pyo or .pyc files. I can run it from Videos -> Add-ons and then after the first full run (and all .pyo and .pyc files are created) it seems to work fine. This started after the change in this TRAC issue: http://trac.xbmc.org/ticket/13325#comment:4

I just tried the latest nightly, but the freezing from the home screen issue is still there. I had more users of my Add-on complain about this to me.

Reply
#23
Sorry. I've been swamped. I'll try to get to it soon.
Reply
#24
Just in case it helps: users of Rom Collection Browser get the same error with recent linux nightlies (not sure if it occurs on windows too). The line of code in RCB is the following:

Code:
item = xbmcgui.ListItem(gameRow[util.ROW_NAME], str(gameRow[util.ROW_ID]), imageGameList, imageGameListSelected)
Reply
#25
I see the problem here. I'll have a fix out today.
Reply
#26
The 'addItem' problem should be resolved with this commit:

https://github.com/xbmc/xbmc/commit/6f04...0aa7860e7a

You can build from the latest master or you can wait until it hits the nightlies.

Thanks for your patience.
Jim
Reply
#27

Ok. It may make sense for me to put back the TypeError simply for backward compatibility. What do you guys think?
Reply
#28
(2012-10-01, 14:17)jfcarroll Wrote: Ok. It may make sense for me to put back the TypeError simply for backward compatibility. What do you guys think?

I am always in favour of throwing the correct type of error. But I guess a lot of add-ons will break because of this change. On the other hand, I guess a lot of add-ons will need some tweaking due to the major changes to the Python interface. So I would keep the new error. For those that create add-ons it will only be a change in a try....except block. It will change into

Code:
try:
    #Do Stuff
except (TypeError, RuntimeError):
    #Catch stuff

So that it will be backward compatible.
Reply
#29
(2012-10-01, 14:59)Basje Wrote:
(2012-10-01, 14:17)jfcarroll Wrote: Ok. It may make sense for me to put back the TypeError simply for backward compatibility. What do you guys think?

I am always in favour of throwing the correct type of error. But I guess a lot of add-ons will break because of this change. On the other hand, I guess a lot of add-ons will need some tweaking due to the major changes to the Python interface. So I would keep the new error. For those that create add-ons it will only be a change in a try....except block. It will change into

Code:
try:
    #Do Stuff
except (TypeError, RuntimeError):
    #Catch stuff

So that it will be backward compatible.

IMO do it like it should.
A lot of things will probably already break due to JSON-API changes.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#30
Ok. I talked to a few others and it seems everyone thinks leaving the RuntimeError is the right approach. So for now I'll leave it like it is.
Reply

Logout Mark Read Team Forum Stats Members Help
WindowXML changes0