[Nuka1195]

does having a <texturefocus> tag in a label control hurt anything? does it just get ignored

i'm trying to have only one place for the main pos tags and width and height tags. so i include the buttons include, which has non label control tags.

i have some weird bugs, that may be skin related, not sure.

[jmarshall]

They get ignored for the most part, but some of the variables used to read the XML tags may be reused in other places. Mostly things like the color tags which differ across different controls though.

Having a texturefocus tag in a label control will not hurt anything.

[Nuka1195]

ok thanks.

i think i have hit a wall on size of includes?

there is a post about this and it was determined there was no limit or that wasn't the problem.

so maybe some weird conflict, easily reproducable. if you would like to test this. i can package up the skin files needed.

i am at a complete loss, why i can add a few <content><item>'s and it works. or i can add them all and not <include> other views.

[andyblac]

i had the same problem months ago with my skin, but no one was willing to help. i even asked if the debug log could report EVERYTHING so i could debug it, but got told no it will not be added. i have loads of problems like this. ie it is the same for the number of buttons in a group. XBMC crashes if a LARGE coded view is loaded before a view thats has loads of button (my customise menu screen). thats why i also asked if XBMC could unloaded (from memory) anything that is not used when entering a new part of the skin, but got no reply.

it just seems that we are indeed hitting the limits of the current skinning engine, with our complex skins. i mean Confluence is BASIC in comparison to mine and others. i have loads of idea's for my new skin but with the current XBMC skinning engine it is noway going to come to life.

[Jezz_X]

what I don't get is why do people insist on <include>ing everything these days. Whats wrong with actually putting the code where it is suppossed to be instead of including 5 different levels of stuff take aeon for example the the actual myvideonav.xml is 15 lines big but includes 3000 plus lines of actual code.

[andyblac]

what I don't get is why do people insist on <include>ing everything these days. Whats wrong with actually putting the code where it is suppossed to be instead of including 5 different levels of stuff take aeon for example the the actual myvideonav.xml is 15 lines big but includes 3000 plus lines of actual code.

so will that help ?, i don't use includes in my settings areas but still have problems with that area, once a library view is loaded ?

EDIT:
also is it better to code a view that has code for ALL views (movies, tvshows & music) or have separate code for one for each.
ie 1 list view 50 (one for all) or 3 list views for for each. 50 (movies), 51 (TV) & 52 (music)

EDIT2:
even confluence have includes added to it's MyVideoNav.xml for it views, what you say we should not be doing ?

[Nuka1195]

i'm not five levels deep. i create the content file seperately so skinners could also use it.

it's quite big and easier to create with a python script, than type or copy and paste and change numbers. 30 items per list,

<item>
<label>$INFO[Window.Property(MapList.1.MapLabel.1)]</label>
<label2>$INFO[Window.Property(MapList.1.MapLabel2.1)]</label2>
<icon>$INFO[Skin.String(TWC.MapIconPath)]$INFO[Window.Property(MapList.1.MapIcon.1)]</icon>
<onclick>SetProperty(Weather.CurrentMap,$INFO[Window.Property(MapList.1.MapLabel.1)])</onclick>
<onclick>$INFO[Window.Property(MapList.1.MapOnclick.1)]</onclick>
<onclick>SetFocus(2000)</onclick>
<visible>!IsEmpty(Window.Property(MapList.1.MapLabel.1))</visible>
</item>

so could there be an id conflict? too many window.properties?

it always affects the same windows. video info dialog (i think), the one when you press I in video library and it also sometimes affects scripts window. the list will not display.

if i first go into either of those windows, then try the weather window. it crashes. the log doesn't output an error, but if it would help, i will get one.

i thought maybe jmarshall could trace debug it and see if it's the window properties. there are a lot of them being created. i can get a count if that would help.

[Jezz_X]

so will that help ?, i don't use includes in my settings areas but still have problems with that area, once a library view is loaded ?

EDIT:

also is it better to code a view that has code for ALL views (movies, tvshows & music) or have separate code for one for each.

ie 1 list view 50 (one for all) or 3 list views for for each. 50 (movies), 51 (TV) & 52 (music)

I'm not going to claim to be an authority on this but my include comment was more about "why" not that its wrong all it does is make really confusing code to read when 90% of the time its not needed
As for the views I would think having seperate ones with visible conditions would be better but jmarshall is probably the best to answer. You have to take into acount that everything <include>d is loaded as soon as the skin loads and held in memory for the whole time the skin is running and used as needed. Thats why you have to reload the skin to show any changes to includes because they only get loaded once at the skin load. so if you include 95% of your skin it all just sits in memory the whole time

i'm not five levels deep. i create the content file seperately so skinners could also use it.

it's quite big and easier to create with a python script, than type or copy and paste and change numbers. 30 items per list,



so could there be an id conflict? too many window.properties?

it always affects the same windows. video info dialog (i think), the one when you press I in video library and it also sometimes affects scripts window. the list will not display.

if i first go into either of those windows, then try the weather window. it crashes. the log doesn't output an error, but if it would help, i will get one.

i thought maybe jmarshall could trace debug it and see if it's the window properties. there are a lot of them being created. i can get a count if that would help.

I got no idea but why would you want to set weather properties for every single window like DialogVideoInfo that seems crazy and over kill and not needed to me. but maybe its because they are dialogs and not windows so window.Property doesn't work for it and sets it for the main window instead ?

[Nuka1195]

i don't set properties for any window but weather jezz. thats just a window that is affected by this.

and by holding all those includes in memory could that be my conflict?

i can combine this into one file, but it would still be an include file or else the myweather.xml will huge for those that don't use the plugin.

[Hitcher]

I didn't realise that the includes are all loaded from the start and keep in the memory, I thought they were only loaded when entering the window they're used in.

Having said that, I now try to use includes that are conditional to the skin settings so if they're not used they wont get a loaded which, I'm assuming, is better then using visible conditions as they're constantly checked when in use.

It's one big balancing act really.

[phil65]

Same problem here... Would also love to add new things, but these "bugs" really annoy me and keep me away from skinning.

[ronie]

ok thanks.

i think i have hit a wall on size of includes?

there is a post about this and it was determined there was no limit or that wasn't the problem.

so maybe some weird conflict, easily reproducable. if you would like to test this. i can package up the skin files needed.

i am at a complete loss, why i can add a few <content><item>'s and it works. or i can add them all and not <include> other views.

in my experience it's the number of <visible> conditions that could result in strange behavior.
back in the skin-based media flagging days, i had a <visible> condition for every studio icon (over 200 in total),
this resulted in weird things like disappearing backgrounds, missing items on the contextmenu, missing buttons in the shutdown menu...

after cutting down the list of studio icon to, let's say, a 100, all of these issues went away.

[Nuka1195]

ah, each one of those content items needs a visible tag or else you would get a list of blank lines. i think.

[ronie]

ah, each one of those content items needs a visible tag or else you would get a list of blank lines. i think.

maybe you could temporary comment-out the visible conditions, just to test if it solves the bugs you're experiencing.

[andyblac]

in my experience it's the number of <visible> conditions that could result in strange behavior.
back in the skin-based media flagging days, i had a <visible> condition for every studio icon (over 200 in total),
this resulted in weird things like disappearing backgrounds, missing items on the contextmenu, missing buttons in the shutdown menu...

after cutting down the list of studio icon to, let's say, a 100, all of these issues went away.

that would explain the problems i have with my settings screen, i have loads (111) of buttons all with visible's that show when a certain control focus is met. and if you add those to all the other in skin that are loaded i can imagine that they will be 300+

JM is they anything we can do about this ?