WindowXML GUI Toolkit (replaces GUIBuilder for XBMC python scripts for GUI coding)

I also struck a similar problem. My problem also occurs allot more on the xbox than on the PC (memory problem?). It's when I add list items like you have, but I am using two methods of adding them, one is to add them to the top of the list, and the other is to add them to the bottom of the list - this problem annoyed me so much it ended my creative spree :-(

It appears to fail when used in a loop (multiple items being added), but not just when one item is added.

stanley87 Wrote:I also struck a similar problem. My problem also occurs allot more on the xbox than on the PC (memory problem?). It's when I add list items like you have, but I am using two methods of adding them, one is to add them to the top of the list, and the other is to add them to the bottom of the list - this problem annoyed me so much it ended my creative spree :-(

It appears to fail when used in a loop (multiple items being added), but not just when one item is added.

Although it is not great that something like this is happening, I am glad to hear I am not the only one experiencing the problem. The only thing that we need is a solution. Does this problem sound familiar to one of the Devs?

@Nuka1195
I think on
As for getListSize(), the reason i didn't go with getSize is little bit ambious what it means, after all its a WindowXML, 'getSize implies it gets the size of the window' hence why i chose getListSize(), most the other stuff is getCurrentListPosition and getListItem. Ideally i would have pefered something like self.list.addItem() etc (where list is like a 'controlwindowlist' thats automatically part of the WindowXML like the otehr methods. The idea would be controlwindowlist ineheirt ControlList and overwrite the methods to provide the infomation from the 'window lists', but i wasn't sure about that.

I tried labeling most the 'WindowList' specific stuff with the 'List' in the name, plus then u don't get confused and think self is suddenly an actual list control.

My getListItem changes are in rev 9223, and few others things are different there as well.

Basje) i don't get an exception like that on XBMC_PC, yet to try my new script on XBOX with WindowXML . (i had an older one taht used WindowXML and creates listitems/ on screen fine.

Both my scripts uses a loop to create items from an array
I might be able to release the new script as a new demo. (part of a bigger script i want to redo

donno Wrote:@Nuka1195
Basje) i don't get an exception like that on XBMC_PC, yet to try my new script on XBOX with WindowXML . (i had an older one taht used WindowXML and creates listitems/ on screen fine.

It only happens like once every 50 lists I try to fill on my XBMC_PC, but once very 10 lists on XBMC. The first is acceptable, but the latter is much to frequent.

Basje, my problem has now fixed in REV 9286.
GIVE IT A TRY! :-D

stanley87 Wrote:Basje, my problem has now fixed in REV 9286.
GIVE IT A TRY! :-D

I saw the changelog and will do a build tomorrow. I will let you know the results.

Some tips for using non-native controls in WindowXML.

1. wrap the control in a group. This allows setting it visible or hidden.
2. use xbmc.executebuiltin( "Skin.SetString(setting-name,setting-value") ) for any info you need to change(e.g.<info>Skin.String(AMT-thumbfolder)</info> for a multiimage control)
3. to use a media panel control. make sure you have a media list control and always reference the media list control for getListItem() and things.

The getPosition() python method returns what the controls <posx>, <posy> tags are for a list control.

If the control is inside a group when the group has it's own <posx> or <posy>, or if there is a coordinates system. It does not take that into account.

Is thers a way to return the actual position?

I need the actual position to center a context menu.

Not at this point, no.

One way to do it would be to:

1. Grab controls position.

2. Iterate up through it's parents and add their positions.

3. Finally, add the window's position (may not be it's GetPosition() stuff due to conditional origins!)

Alternatively you could implement a CGUIWindow::GetControlPosition(id) routine that does the same thing but in a different way:

1. Iterate through controls. If the id matches, we return it's position + the window position.

2. Else, if it's a group, we call the groups' GetControlPosition function.

3. Once we have a position, we return it.

It's similar to how the mouse handling works (See FocusFromPoint and UnfocusFromPoint).

This will give you the position in the window's XML resolution coordinates relative to the screen. It's probably what you want, but may not be if the context menu's dialog was in a different coordinate system (unlikely though).

Cheers,
Jonathan

[quote]It's probably what you want, but may not be if the context menu's dialog was in a different coordinate system (unlikely though)./QUOTE]

I can adjust in the context_menu.xml. That never occured to me. Since it's the same skin, won't be an issue. I didn't realize the coordinates was used if I set the position from python.

Thanks it works perfect,

I still like being able to grab the actual position, so maybe I'll see what I can do.